CPU Configuration Guidelines for vPars

4 Configuring the CPU’s on vPars

In the previous section it was determined experimentally that 4 CPU’s are required to sustain the

steady state workload and meet the 60% CPU utilization objective. The experiment also determined

that 6 CPU’s are required to sustain the peak workload and meet the 60% CPU utilization objective.

Now that the CPU configuration to meet these performance objectives is known, it should be a simple

matter to configure the CPU’s for the vPar. On systems running vPars versions prior to A.04.01 you

simply set the minimum number of CPU’s to 4 and the maximum number of CPU’s to 6 and you are

done. The following is an example of how to set the minimum and maximum CPU parameters with the

vparmodify command. This command can only be performed while the vPar is in the down state.

vparmodify –p vpolyc01 –m cpu:::4:6

Note:

Refer to the vparresources(5) manual page for the syntax to modify the minimum and

maximum CPU attribute.

4.1 I/O Interrupt Assignment on HP-UX

The same vparmodify command issued above can and will work on on vPars prior to A.04.01 as well

as on A.04.01 with the caveat that performance on A.04.01 may be inconsistent between runs. The

major contributor to this variability is uneven distribution of I/O interrupt processing due to uneven

I/O interrupt assignment.

As stated in the beginning of this paper, the HP-UX kernel assigns I/O interrupts to CPU’s using a

round robin algorithm. As each I/O device is discovered and bound to its driver, the drivers interrupt

service routine is registered to execute on a specific CPU. When an I/O device signals completion of

a DMA operation, the CPU that it is assigned to is interrupted and the devices I/O interrupt handler is

invoked to service the interrupt.

When a CPU is removed from a vPar, the processes and I/O interrupts that are assigned to it are

distributed amongst the remaining CPU’s. These same set of tasks are used to unload a CPU when it is

moved from the default processor set to the real-time processor set. When a CPU is migrated into a

vPar, the CPU will be assigned a portion of the processing load but will not be assigned any I/O

interrupts. Over time, I/O interrupts from other CPU’s migrating out of the system may be assigned to

this CPU. If many CPU migrations take place, the majority of the I/O interrupts may land on too few

CPU’s or worse case on the boot CPU. If the I/O load is high enough, response time may increase

and throughput may decrease due to this imbalance.

4.2 CPU Configuration on A.04.01

On A.04.01, any CPU other than the boot CPU is eligible to migrate in or out of a vPar. If CPU’s are

specified by count, the vPars monitor decides which CPU’s to migrate. A CPU migration into a vPar

by count is not guaranteed to be the same CPU chosen to migrate out of the vPar when specified by

count. The consequence of this CPU selection algorithm may lead to conditions where I/O interrupts

become less distributed. This can lead to a condition where the CPU’s handling interrupts can become

so burdened with interrupt processing that applications running on them may experience increased

response times. If the system becomes too unbalanced the performance of the vPar may become

erratic.

There is method to configure CPU’s with vPars that will prevent the uneven distribution of interrupts

caused by CPU migration. This method involves specifying CPU’s by path and by count. Using pre

A.04.01 terminology, the path based CPU’s represent the bound or minimum CPU’s and the count

based CPU’s represent the unbound or floating CPU’s. The key to making this method work is to use