Power6 (AIX v6.1)


 

+

Search Tips   |   Advanced Search

 

LPARs running on POWER6 systems running AIX v6.1 can be part of a shared pool of CPUs, operating in one of three modes:

guaranteed If an LPAR is using its entitled capacity, no donating or borrowing occurs.
borrowing When an LPAR exceeds entitled capacity, it borrows spare cycles from another LPAR.
donating If an LPAR is not using all of its entitlement, it can donate cycles to the pool for other LPARs to use.

In terms of CPUs (processors)

For LPARs...

CPU utilization greater than 100 percent is a good thing in a shared pool, as you're using spare cycles. When measuring utilization, do it at the frame level so we can see what all of the LPARs are doing.

The pool automatically uses all activated, non-dedicated cores. Any capacity upgrade-on-demand CPUs that are physically installed in the frame but not activated are not part of the pool. If a processor is marked down and removed from the pool, the machine will automatically activate one of the deactivated CPUs and add it to the pool.

The number of virtual processors specified for an LPAR represents the maximum number of physical processors the LPAR can access. If the pool has 32 processors in it, but the LPAR only has four virtual CPUs and is uncapped, the most it can consume will be four CPUs.

You cannot share pooled processors until the number of virtual processors exceeds the size of the shared pool. If we have pool with two LPARs and four CPUs, and each LPAR had two virtual CPUs, there would be no benefit to sharing CPUs. As you start adding more LPARs and virtual CPUs to the shared pool, eventually you'll have more virtual processors than physical processors. This is when borrowing and donating cycles based on LPAR activity comes into play.

The sum total of assigned processing units cannot exceed the size of the shared pool. You cannot guarantee four CPUs worth of processing power if we only have three CPUs available.

Capped LPARs are limited to their processing-unit setting and cannot access extra cycles. Uncapped LPARs have a weight factor, which is a share-based mechanism for the distribution of excess processor cycles. The higher the number, the better the chances the LPAR will get spare cycles; the lower the number, the less likely the LPAR will get spare cycles.

The HMC establishes a guaranteed amount of processor cycles for each LPAR.

If set to...

Uncapped = Yes

...an LPAR can utilize excess cycles.

If set to...

Uncapped = No

...an LPAR is limited to the desired processing units. When you select your desired virtual processors, you establish an upper limit for an LPARs possible processor consumption.

If an LPAR has two virtual processors...

If an LPAR has four virtual processors...

For an LPAR that has two virtual processors, with a desired 1.6 processing units, if both virtual processors have work to be done, each will receive 0.8 processing units.

If there are excess processing units, LPARs with a higher desired virtual-processor count are able to access more excess processing units. For example, an LPAR with...

In this case, each virtual processor will receive 1.0 processing units from the 5.8 available. The maximum number of processing units that can be consumed is four, because there are four virtual processors. If the LPAR only has two virtual processors, each virtual processor will receive 1.0 processing units from the 5.8 available, and the maximum processing units that can be consumed is two, because we only have two virtual processors.

The minimum and maximum settings in the HMC have nothing to do with resource allocation during normal operation. Minimums and maximums are limits applied only when making a dynamic change to processing units or virtual processors using the HMC. The minimum setting also allows an LPAR to start with less than the desired resource allocations.

 

Related tasks

Tuning Windows systems
Tuning Linux systems
Tuning Solaris systems
Tuning HP-UX systems