Controlling Processor Use

On a multiprocessor system, the use of processors can be controlled in two ways:

• A system administrator can control the availablity of the processors for the whole system.
• A user can force a process or kernel threads to run on a specific processor.

Read the following to learn more about controlling the processor use:

• The cpu_state Command
• Example Processor Configurations
• Binding Processes and Kernel Threads

The cpu_state Command

A system administrator (or any user with root authority) can use the cpu_state command to list system processors or to control available processors. This command can be used to list the following information for each configured processor in the system:

It is important to note that the cpu_state command does not display the current processor state, but instead displays the state to be used for the next system start up (enabled or disabled). If the processor does not respond, it is either faulty (an ODM state) or a communication error occured. In this case, the cpu_state command displays No Reply .

Example Processor Configurations

The examples that follow show various processor configurations and how they affect the output of the cpu_state command. After presenting simple cases, more complex configurations involving disabled or faulty processors are shown. These examples illustrate the relationships among physical processor numbers, logical processor numbers, the current processor state, and the processor state used at the next boot.

Simple Processor Configurations

The simplest case to consider is when all available processors on a system are functionning and enabled. Consider a simple two processor system with both processors enabled. The various ODM and number conventions are shown in the following table.

For the above configuration, the cpu_state -l command produces a listing similar to the following:

Name    Cpu      Status     Location
proc0    0       Enabled    00-0P-00-00
proc1    1       Enabled    00-0P-00-01

Now, suppose that the system is upgraded by adding an additional CPU card with two processors. By default, processors are enabled, so the new configuration is shown in the following table.

For this configuration, the cpu_state -l command produces a listing similar to the following:

Name    Cpu      Status     Location
proc0    0       Enabled    00-0P-00-00
proc1    1       Enabled    00-0P-00-01
proc2    2       Enabled    00-0Q-00-00
proc3    3       Enabled    00-0Q-00-01

Complex Processor Configurations

A processor can fail a boot power-on test and be marked faulty by ODM. A processor can also be disabled for maintenance or test reasons. In either case, the processor is not enabled and, thus, does not have a logical processor number. Also, when a processor is enabled or disabled using the cpu_state command, its current state remains unchanged until the next boot, but its state at the next boot (displayed in the Status field of the cpu_state command) is changed immediately.

Disabled Processor Configurations

Using the four processor configuration in the previous section, the physical processor 1 can be disabled with the command:

cpu_state -d proc1

The processor configuration is shown in the following table.

For this configuration, the cpu_state -l command produces a listing similar to the following:

Name    Cpu      Status     Location
proc0    0       Enabled    00-0P-00-00
proc1    1       Disabled   00-0P-00-01
proc2    2       Enabled    00-0Q-00-00
proc3    3       Enabled    00-0Q-00-01

When the system is rebooted, the processor configuration is as shown in the following table.

The output of the cpu_state -l command is similar to the following:

Name    Cpu      Status     Location
proc0    0       Enabled    00-0P-00-00
proc1    -       Disabled   00-0P-00-01
proc2    1       Enabled    00-0Q-00-00
proc3    2       Enabled    00-0Q-00-01

Faulty Processor Configurations

Using the last processor configuration discussed in the previous section, suppose that the system is rebooted and that processors proc0 and proc3 fail their power-on tests. The processor configuration is as shown in the following table.

The output of the cpu_state -l command is similar to the following:

Name    Cpu      Status     Location
proc0    -       No Reply   00-0P-00-00
proc1    -       Disabled   00-0P-00-01
proc2    0       Enabled    00-0Q-00-00
proc3    -       No Reply   00-0Q-00-01

Binding Processes and Kernel Threads

Users may also force their processes to run on a given processor; this action is called binding. A system administrator may bind any process. From the command line, binding is controlled with the bindprocessor command.

It is important to understand that a process itself is not bound, but rather its kernel threads are bound. Once kernel threads are bound, they are always scheduled to run on the chosen processor, unless they are later unbound. When a new kernel thread is created, it has the same bind properties as its creator.

This applies to the initial thread in the new process created by the fork subroutine: the new thread inherits the bind properties of the thread which called the fork subroutine. When the exec subroutine is called, bind properties are left unchanged. Thus, once a process is bound to a processor, if no other binding or unbinding action is performed, all child processes will be bound to the same processor.

It is only possible to bind processes to enabled processors using logical processor numbers. Available logical processor numbers can be listed using the bindprocessor -q command. For a system with four enabled processors, this command produces output similar to:

The available processors are: 0 1 2 3

Binding may also be controlled within a program using the bindprocessor subroutine, which allows the programmer to bind a single kernel thread or all kernel threads in a process. The programmer can also unbind either a single kernel thread or all kernel threads in a process.

Related Information

Programming on Multiprocessor Systems: Overview

Identifying Processors

The cpu_state command, bindprocessor command.

The bindprocessor subroutine.