Multiple Shared Processor Pools: Entitled Pool Capacity

Distribution of processor shares to shared processor pools and LPARs in the default shared processor pool according to EPC or EC.

An important change when using shared processor pools in PowerVM concerns the distribution of unused processor shares of the LPARs. Without shared processor pools, unused processor shares are divided among all uncapped LPARs according to their weights. As soon as shared processor pools are used, the distribution takes place in two stages. Unused processor shares are first distributed to uncapped LPARs within the same shared processor pool. Only the unused processor shares that are not consumed by other LPARs in the same shared processor pool are redistributed to LPARs in other shared processor pools.

Each shared processor pool has a so-called Entitled Pool Capacity (EPC), which is the sum of the guaranteed entitlements of the assigned LPARs and the Reserved Pool Capacity (RPC). The reserved pool capacity can be configured using the reserved_pool_proc_units attribute of the shared processor pool and has the default value 0. Just as the entitlement is guaranteed for a shared processor LPAR, the assignment of the entitled pool capacity is guaranteed for a shared processor pool , regardless of how the shares are then distributed to the associated LPARs in the shared processor pool. Figure 5.15 shows reserved, entitled and maximum pool capacities for a shared processor pool.

The following condition must always be met for the pool capacities:

Reserved Pool Capacity <= Entitled Pool Capacity <= Maximum Pool Capacity

The pool capacities are always shown in the output of “ms lsprocpool“:

$ ms lsprocpool ms06
MS_NAME  PROCPOOL      ID  EC_LPARS  RESERVED  PENDING  ENTITLED  MAX
ms06     DefaultPool   0   7.90      -         -        7.90      -
ms06     SharedPool01  1   0.60      0.10      0.10     0.70      1.00
$

In the column EC_LPARS the guaranteed entitlements of the assigned LPARs are added up, here 0.60 for the pool SharedPool01. The column RESERVED shows the reserved pool capacity (0.10 for SharedPool01), the column ENTITLED shows the entitled pool capacity and finally the column MAX shows the maximum pool capacity. (The SharedPool01 is the shared processor pool from Figure 5.15.)

The figure above shows how the distribution of processor shares works in the presence of several shared processor pools.

Each shared processor pool receives a share of the processors (cores) according to its entitled pool capacity. Shared processor LPARs in the default shared processor pool receive processor shares according to their entitlement. The unused processor shares are distributed to all LPARs, regardless of shared processor pools, according to their weights (this is not shown in the diagram).

The processor shares assigned to each shared processor pool (according to the entitled pool capacity) are then distributed within the shared processor pool to the associated LPARs according to their entitlement. That means in particular that every LPAR in a shared processor pool continues to receive its guaranteed entitlement!

If an LPAR in a shared processor pool does not consume its entitlement, then these unused processor shares are first distributed within the shared processor pool to other LPARs that need additional processor shares. The distribution then takes place as before, taking into account the weights of the LPARs. Unused processor shares are thus, so to speak, “recycled” within a shared processor pool. If not all unused processor shares in the shared processor pool are used up in this way, then these are redistributed to all LPARs (LPARs with a need for additional processor shares) via the hypervisor, regardless of the associated shared processor pool.

This two-stage distribution of processor shares can be observed very well in a small experiment. We have increased the guaranteed entitlement to 0.8 for the 3 LPARs (lpar1, lpar2 and lpar3):

$ lpar addprocunits lpar1 0.4
$ lpar addprocunits lpar2 0.4
$ lpar addprocunits lpar3 0.4
$

The assignment to the shared processor pools remains: lpar1 and lpar2 are assigned to the shared processor pool benchmark and lpar3 remains assigned to the default pool:

$ lpar -m ms11 lsproc
           PROC         PROCS           PROC_UNITS                        UNCAP   PROC    
LPAR_NAME  MODE    MIN  DESIRED  MAX  MIN  DESIRED  MAX  SHARING_MODE     WEIGHT  POOL
lpar1      shared  1    4        8    0.1  0.8      2.0  uncap            100     benchmark
lpar2      shared  1    4        8    0.1  0.8      2.0  uncap            100     benchmark
lpar3      shared  1    4        8    0.1  0.8      2.0  uncap            100     DefaultPool
ms11-vio1  ded     1    7        8    -    -        -    keep_idle_procs  -       -
ms11-vio2  ded     1    6        8    -    -        -    keep_idle_procs  -       -
$

In the shared processor pool benchmark, the resulting entitled pool capacity is 2 * 0.8 + 0.0 = 1.6 (the reserved pool capacity is 0.0). The entitled pool capacity of the default Shared Processor Pool with only one LPAR is 0.8.

$ ms lsprocpool ms11
MS_NAME  PROCPOOL     ID  EC_LPARS  RESERVED  PENDING  ENTITLED  MAX
ms11     DefaultPool  0   0.80      -         -        0.80      -
ms11     testpool     1   0.00      0.00      0.00     0.00      2.00
ms11     benchmark    2   1.60      0.00      0.00     1.60      2.00
$

We start the benchmark again, this time on lpar1 (shared processor pool benchmark) and lpar3 (shared processor pool DefaultPool) in parallel. No load is placed on lpar2 (Shared Processor Pool benchmark), the LPAR is at a load of approx. 0.00 – 0.01 during the benchmark. This means that the guaranteed entitled pool capacity of 1.6 is available exclusively for lpar1! The guaranteed entitlement of lpar2 in the default pool is only 0.8. Of the 3 physical processors (cores) in the physical shared processor pool, only an entitlement of 3.0 – 1.6 – 0.8 = 0.6 remains, which can be distributed to LPARs with additional processor components. Since lpar1 and lpar3 both have the same weights (uncap_weight=100), they each receive an additional 0.3 processing units. That makes for lpar1: 1.6 + 0.3 = 1.9. And for lpar3: 0.8 + 0.3 = 1.1. This can be seen very nicely in the graphics for the processor utilization (figure 5.17). A short time after the start of the benchmark, on lpar1 around 1.9 physical processors (cores) are used and on lpar3 around 1.1. Due to the larger processor shares, the benchmark on lpar1 is finished faster, which means that the processor utilization goes down there. However, lpar3 has then more processor shares available and lpar3 then takes almost all of the 3 available processors at the end.

Without additional shared processor pools, all uncapped LPARs benefit from unused processor shares that an LPAR does not use. Since potentially all LPARs get shares of these unused processor shares, the proportion for an individual LPAR is not so large. If additional shared processor pools are used, uncapped LPARs in the same shared processor pool benefit primarily from unused processor shares of an LPAR. These are fewer LPARs and therefore the proportion of additional processor capacity per LPAR is higher.

5.5. Multiple Shared Processor Pools

5.5.1. Physical Shared Processor Pool

5.5.2. Multiple Shared Processor Pools

5.5.3. Configuring a Shared Processor Pool (Maximum Pool Capacity)

5.5.4. Assigning a Shared Processor Pools

5.5.5. Entitled Pool Capacity (EPC)

5.5.6. Reserved Pool Capacity (RPC)

5.5.7. Deactivating a Shared Processor Pool