5.2. Shared Processors (Micro-Partitioning)
If a dedicated processor is only used to a limited extent, the unused computing power is wasted. Therefore, with the introduction of POWER5 systems from IBM, micro partitioning was introduced. One or more processors are used jointly by several LPARs. This achieves a higher utilization of the processors. The computing power of a physical processor is divided into 100 parts. Each part corresponds to 0.01 processing units (1 hundredth of a processor or 1% of a processor). Processing units with a granularity of 0.01 processing units can then be assigned to the LPARs.
Figure 5.2 shows the division of of a physical processor into processor shares for 3 LPARs. LPAR1 receives 0.15 processing units (15%), LPAR2 receives 0.10 processing units (10%) and LPAR3 receives 0.15 processing units (15%) of the processing power of the processor. In total, this is 0.40 processing units (40%), which means that 0.60 processing units (60%) would be available for further LPARs. The term micro-partitioning comes from the fact that a resource is divided into further parts. With the dedicated processors, a whole processor is always assigned to an LPAR as the smallest unit, with micro-partitioning a processor is further divided (into 100 parts) and these smaller parts can be assigned to different LPARs.
The processing units assigned to an LPAR are called entitlement or entitled capacity. The hypervisor guarantees that an LPAR gets assigned the entitled capacity under all circumstances, regardless of the current utilization of the underlying hardware.
The allocation of the shares of a physical processor to the associated LPARs takes place in a time slice method. The hypervisor assigns the LPARs a share of the processor time according to the configured shares in every 10 ms time interval. A physical processor is thus used jointly by several LPARs, hence the term shared processor for the jointly used physical processor, as well as shared processor LPAR for an LPAR which uses shared processors. As shown in Figure 5.3, each LPAR is assigned the shared processor for a short time interval (according to the configured shares of the LPAR) during each 10 ms time interval. The yellow LPAR from the figure with 0.15 processing units is assigned a share of 1.5 ms in every 10 ms time interval.
As with LPARs with dedicated processors, the number of processors required can be specified when creating shared processor LPARs. However, no physical processors are assigned, but so-called virtual processors. A virtual processor in an LPAR allows shares in a physical processor to be obtained in accordance with the above-mentioned time slice method. If an LPAR is configured with 8 virtual processors, for example, then it can use up to 8 physical processors in parallel. How many shares the LPAR receives from the physical processors is determined as usual by the assigned entitlement (or entitled capacity) of the LPAR.
Unless otherwise specified, the LPAR tool generates by default shared processor LPARs. The desired number of virtual processors can be specified in the same way as with the dedicated LPARs using the desired_procs attribute:
$ lpar create -m ms02 lpar10 desired_procs=2
.
   > lpar10
$
The attributes min_procs and max_procs, which are already known from the dedicated LPARs, retain their meaning. The two attributes now do not refer to dedicated processors, but to virtual processors. An LPAR can only be activated if at least the number of virtual processors specified by min_procs can be assigned. The number of virtual processors can be changed dynamically online within the limits given by min_procs and max_procs.
The LPAR lpar10 created above has the following configuration:
$ lpar -p standard lsproc lpar10
           PROC        PROCS          PROC_UNITS                   UNCAP     PROC  Â
LPAR_NAMEÂ MODEÂ Â Â MINÂ DESIREDÂ MAXÂ MINÂ DESIREDÂ MAXÂ SHARING_MODEÂ WEIGHTÂ POOL
lpar10    shared 1   2       2   0.2 0.2     0.2 uncap        100    DefaultPool
$
The processor mode (proc_mode) is shared. The minimum number of virtual processors (min_procs) is 1, the desired number of virtual processors (desired_procs) is 2 and the maximum number of virtual processors (max_procs) is also 2.
All physical processors that are not used as dedicated processors are automatically shared processors and form the so-called physical shared processor pool. In figure 5.4, 2 processors (blue) are dedicated processors and the remaining 8 processors (red) are shared processors. The virtual processors of shared processor LPARs are assigned their entitlement from the pool of shared processors. The same physical processor does not necessarily have to be assigned in every 10 ms time interval; the assignment can change if the resource distribution by the hypervisor makes this necessary. The two virtual processors of the shared processor LPAR shown can be assigned to two different physical processors in one time interval, but it is also possible that the same physical processor is assigned to both virtual processors (of course not at the same time). The assignment of virtual processors to physical processors is therefore not fixed, but can change dynamically depending on requirements.
The desired entitlement (entitled capacity) can be specified when creating an LPAR using the desired_proc_units attribute. At least 0.05 processing units must be configured per virtual processor (with POWER7 or older 0.10 processing units). With 2 virtual processors (desired_procs=2), at least 2 * 0.05 = 0.10 processing units must be specified for desired_proc_units. A minimum value (min_proc_units) and a maximum value (max_proc_units) can also be specified for the entitlement. The value of min_proc_units determines the minimum processing units required to activate an LPAR. The values of min_proc_units and max_proc_units determine the range within which the entitlement can be changed dynamically during the runtime of an LPAR. The value of min_proc_units must be less than or equal to the value desired_proc_units, which in turn must be less than or equal to the value max_proc_units:
min_proc_units <= desired_proc_units <= max_proc_units
The following example demonstrates how these attributes can be specified when creating a new LPAR:
$ lpar create -m ms02 lpar11 desired_procs=2 max_procs=4 desired_proc_units=0.8 max_proc_units=1.6
.
   > lpar11
$
The LPAR lpar11 was created with 2 desired virtual processors and a maximum of 4 virtual processors. The desired entitlement (desired_proc_units) is 0.8 processing units and the maximum is 1.6 processing units. The min_procs and min_proc_units attributes that are not explicitly specified, are automatically assigned values by the LPAR tool. All attributes can be viewed by printing the values from the profile standard:
$ lpar -p standard lsproc lpar11
           PROC        PROCS          PROC_UNITS                   UNCAP     PROC  Â
LPAR_NAMEÂ MODEÂ Â Â MINÂ DESIREDÂ MAXÂ MINÂ DESIREDÂ MAXÂ SHARING_MODEÂ WEIGHTÂ POOL
lpar11    shared 1   2       4   0.1 0.8     1.6 uncap        100    DefaultPool
$
If possible, the 0.8 processing units are divided between 2 physical processors, the LPAR is allocated 4 ms (corresponds to 0.4 processing units) from both physical processors in every 10 ms time interval. The allocation can be made to both physical processors at the same time, as shown in Figure 5.5, but it is also possible that the allocation takes place at different times, e.g. on the first physical processor the allocation takes place immediately at the beginning of the 10 ms time interval and on the second physical processor a few milliseconds later. In principle, this can also be different in every 10 ms time interval. It is only guaranteed that the LPAR gets its entitlement of 0.8 processing units in every 10 ms time interval.
If no two physical processors are available, the same physical processor is assigned to both virtual processors. Both virtual processors get allocated a 4 ms from the same physical processor, one after the other, of course. However, this is avoided if possible, for better performance.
The maximum possible entitlement is 1.0 processing units per virtual processor! Together with the condition that an entitlement of at least 0.05 must be configured for each virtual processor, this allows a wide range of possible values. The following table lists the permitted area of the entitlement for a given number of virtual processors:
How many configuration options there are, can be seen even better if you specify the entitlement and look at the minimum and maximum possible number of virtual processors that are possible with the entitlement:
For example, an entitlement of 0.40 can be implemented with 1, 2 or up to 8 virtual processors.
You must be logged in to post a comment.