View as PDF

Virtualization with PowerVM > Practical Introduction > Processor Virtualization > Shared Processors (Micro-Partitioning)

5.2.3. Sharing Mode uncap and uncapped_weight

Shared processor LPARs that use the uncap sharing mode compete with each other for additional CPU time. How much additional CPU time such an LPAR can get depends on three factors:

    • Amount of additional available CPU time that is not allocated to an LPAR.
    • The weighting of the LPAR, this can be set to a value between 0 and 255 for each uncapped shared processor LPAR using the attribute uncapped_weight (the default is 128). The higher the value, the higher the share that the LPAR receives.
    • How many other LPARs are currently competing for additional CPU time and their weights. An LPAR that is idle does not compete for additional CPU time.

The additional CPU shares are then determined as follows:

    1. The weights of all LPARs competing for additional time are added.
    2. The proportion of an individual LPAR results from the quotient of its own weight and the sum of the weights of all competing LPARs.
    3. The share is multiplied by the additional available CPU time.

This is shown in Figure 5.8 for 3 LPARs with the weights LPAR1 150, LPAR2 50 and LPAR3 100. All 3 LPARs compete for the unallocated 6 ms of the physical processor.

Allocation of the additional time according to the weights
Figure 5.8: Allocation of the additional time according to the weights

The shares for the individual LPARs are determined as described above:

1. Building the sum of the weights of all competing LPARs: 150 + 50 + 100 = 300.

2. Determination of the proportion of each LPAR through the calculation of the quotients:

    • LPAR1: 150 / 300 = 1/2
    • LPAR2: 50 / 300 = 1/6
    • LPAR3: 100 / 300 = 2/6

3. This is then multiplied by the available CPU portion of 6 ms:

    • LPAR1: 6.0 ms * 1/2 = 3.0 ms
    • LPAR2: 6.0 ms * 1/6 = 1.0 ms
    • LPAR3: 6.0 ms * 2/6 = 2.0 ms

However, the additional shares of CPU time are not guaranteed and can also change in every 10 ms time interval! For example, another LPAR could be activated, which of course then gets its guaranteed entitlement. Or the entitlement of a running LPAR is increased, which means that less unallocated capacity is available.

If an LPAR does not need all of its guaranteed processing units in a time interval, then the unused processing units are returned to the hypervisor, which then distributes them to other LPARs according to the above scheme.

The weight of an LPAR (uncapped_weight) can be changed dynamically at runtime. The command “lpar chproc” (change processors) can be used for this. In addition to the LPAR name, the uncapped_weight attribute is simply specified with a new value between 0 and 255:

$ lpar chproc aix05 uncapped_weight=100
$

If the value 0 is specified for uncapped_weight, the LPAR cannot receive any additional CPU shares beyond its entitlement. It then behaves exactly like an LPAR with sharing mode cap!

If the weight in a profile is to be changed, the command must be started with the “-p” option and the profile name:

$ lpar -p standard chproc aix05 uncapped_weight=100
$

Figure 5.9 shows the processor utilization of an LPAR with sharing mode uncap. The LPAR was configured with an entitlement of 0.6 (yellow line) and one virtual processor.

Processor utilization of an LPAR with sharing mode uncap
Figure 5.9: Processor utilization of an LPAR with sharing mode uncap

With only one virtual processor, a maximum of at most one physical processor can be used, which is 100%, the maximum possible processor utilization is therefore 1.0 (red line). If an LPAR does not use up its guaranteed entitlement within a time interval, the unused part of the guaranteed portion is left to other LPARs (ceded capacity – light yellow). The used part of the guaranteed portion is shown in green. The following applies: the consumed portion of the guaranteed entitlement plus the ceded capacity is always equal to the guaranteed entitlement. This can be seen very clearly in the graph. Since the LPAR is uncapped, it can receive additional processor shares in addition to the guaranteed share, if required, depending on the amount of available shares and the allocation to other LPARs. The additional processor shares are shown in blue in the figure. However, the green (guaranteed) part plus the blue (additional) part cannot exceed the value 1.0 in total. In the graphic you can see that the consumed processor shares “hit” twice at the value 1.0.

Note: The maximum possible processor utilization depends on the number of virtual processors. In particular, the value of max_proc_units does not indicate the maximum possible number of processing units that an LPAR can have! The value max_proc_units indicates the value up to which the guaranteed entitlement can be increased.