Although the LPAR only has an entitlement of 0.2 and a very low value for its weight (uncap_weight=10), it occupies up to 4 complete processor cores! More is not possible with a configuration with 4 virtual processors.

Of course, the LPAR can only get that much processor shares if there are enough processor resources available and obviously all LPARs with a higher weight have also received large amounts of processor shares. In this respect, one could take the point of view that, in this case, it is good to allocate such a huge amount of processor resources, as these would otherwise not be used. However, one should bear in mind that the performance of the LPAR shown can vary extremely over time. At times when no additional processor shares are available, the LPAR receives only its guaranteed entitlement of 0.2 (green area in the picture). At other times, when a lot of processor resources are available, it can use up to 4.0 physical processor cores. That is 20 times more than the guaranteed entitlement. The performance of the LPAR can then also increase 20 times. That means the performance of the LPAR is extremely variable, sometimes the performance is low (only the entitlement is available), sometimes the performance is 20 times higher (4 complete physical processor cores are available). In many cases this behavior is undesirable.

With the introduction of Multiple Shared Processor Pools (MSPP) it is possible to limit the use of processor shares for LPARs. Up to 64 shared processor pools can be configured, and a maximum pool capacity can be assigned to each of the pools. Shared processor LPARs can then be assigned to the processor pools. They can in total consume at most the configured maximum pool capacity. But this is only one of the possibilities offered by the use of multiple shared processor pools.