Shared processors

Shared processors are physical processors whose processing capacity is shared among multiple logical partitions. The ability to divide physical processors and share them among multiple logical partitions is known as the Micro-Partitioning® technology.

Note: For some models, the Micro-Partitioning technology is an option for which you must obtain and enter a PowerVM® Editions activation code.

By default, all physical processors that are not dedicated to specific logical partitions are grouped together in a shared processor pool. You can assign a specific amount of the processing capacity in this shared processor pool to each logical partition that uses shared processors. Some models allow you to use the HMC to configure multiple shared processor pools. These models have a default shared processor pool that contains all the processors that do not belong to logical partitions that use dedicated processors or logical partitions that use other shared processor pools. The other shared processor pools on these models can be configured with a maximum processing unit value and a reserved processing unit value. The maximum processing unit value limits the total number of processing units that can be used by the logical partitions in the shared processor pool. The reserved processing unit value is the number of processing units that are reserved for the use of uncapped logical partitions within the shared processor pool.

You can assign partial processors to a logical partition that uses shared processors. Processing units are a unit of measure for shared processing power across one or more virtual processors. One shared processing unit on one virtual processor accomplishes approximately the same work as one dedicated processor.

The minimum number of processing units depends on the firmware level.

Table 1. Firmware level and processing units per virtual processor
Firmware level	Minimum number of processing units per virtual processor
FW740, or earlier	0.10
FW760, or later	0.05

Some server models allow logical partitions to use only a portion of the total active processors on the managed system, so you are not always able to assign the full processing capacity of the managed system to logical partitions. This is true for server models with one or two processors, where a large portion of processor resources is used as overhead.

When the firmware is at level FW760, or later, overall server performance can be impacted when there are too many virtual processors that are configured on the managed system. You can verify the number of configured virtual processors by using the lshwres command from the HMC command line. The result of the lshwres command might look like the following output:

lshwres -m sysname -r proc --level sys -F curr_sys_virtual_procs,max_recommended_sys_virtual_procs
4,240

where:

curr_sys_virtual_procs indicates the current number of configured virtual processors.
max_recommended_sys_virtual_procs indicates the recommended maximum number of configured virtual processors.

It is suggested that the number of configured virtual processors not exceed the maximum number so that server performance is not affected.

The maximum number of active virtual processors for a shared processor partition is limited by a number of factors. On Power 795, Power 870, Power 880, Power 870C, and Power 880C model servers, the firmware has a limit of 128 active shared virtual processors per partition. On all other models of POWER7 and POWER8, the firmware has a limit of 64 active shared virtual processors per partition.

Note: The limits on the number of active virtual processors for a shared processor partition is for the firmware, but different operating systems and different operating system versions might impose limits lower than the firmware limits.

On HMC-managed systems, shared processors are assigned to logical partitions that use partition profiles.

Logical partitions that use shared processors can have a sharing mode of capped or uncapped. An uncapped logical partition is a logical partition that can use more processor power than its assigned processing capacity. The amount of processing capacity that an uncapped logical partition can use is limited only by the number of virtual processors assigned to the logical partition or the maximum processing unit that is allowed by the shared processor pool that the logical partition uses. In contrast, a capped logical partition is a logical partition that cannot use more processor power than its assigned processing units.

For example, logical partitions 2 and 3 are uncapped logical partitions, and logical partition 4 is a capped logical partition. Logical partitions 2 and 3 are each assigned 3.00 processing units and four virtual processors. Logical partition 2 currently uses only 1.00 of its 3.00 processing units, but logical partition 3 currently has a workload demand that requires 4.00 processing units. Because logical partition 3 is uncapped and has four virtual processors, the server firmware automatically allows logical partition 3 to use 1.00 processing units from logical partition 2. This increases the processing power for logical partition 3 to 4.00 processing units. Soon afterward, logical partition 2 increases its workload demand to 3.00 processing units. The server firmware therefore automatically returns 1.00 processing units to logical partition 2 so that logical partition 2 can use its full, assigned processing capacity once more. Logical partition 4 is assigned 2.00 processing units and three virtual processors, but currently has a workload demand that requires 3.00 processing units. Because logical partition 4 is capped, logical partition 4 cannot use any unused processing units from logical partitions 2 or 3. However, if the workload demand of logical partition 4 decreases below 2.00 processing units, logical partitions 2 and 3 might use any unused processing units from logical partition 4.

By default, logical partitions that use shared processors are capped logical partitions. You can set a logical partition to be an uncapped logical partition if you want the logical partition to use more processing power than its assigned amount.

Although an uncapped logical partition can use more processor power than its assigned processing capacity, the uncapped logical partition can never use more processing units than its assigned number of virtual processors. Also, the logical partitions that use a shared processor pool can never use more processing units than the maximum processing units configured for the shared processor pool.

If multiple uncapped logical partitions need more processor capacity at the same time, the server can distribute the unused processing capacity to all uncapped logical partitions. This distribution process is determined by the uncapped weight of each of the logical partitions.

Uncapped weight is a number in the range of 0 through 255 that you set for each uncapped logical partition in the shared processor pool. On the HMC, you can choose from any of the 256 possible uncapped weight values. By setting the uncapped weight (255 being the highest weight), any available unused capacity is distributed to contending logical partitions in proportion to the established value of the uncapped weight. The default uncapped weight value is 128. When you set the uncapped weight to 0, no unused capacity is distributed to the logical partition.

When the firmware is at level FW830, or earlier, uncapped weight is used only when more virtual processors consume unused resources than the available physical processors in the shared processor pool. If no contention exists for processor resources, the virtual processors are immediately distributed across the physical processors, independent of their uncapped weights. This can result in situations where the uncapped weights of the logical partitions do not exactly reflect the amount of unused capacity.

For example, logical partition 2 has one virtual processor and an uncapped weight of 100. Logical partition 3 also has one virtual processor, but an uncapped weight of 200. If logical partitions 2 and 3 both require more processing capacity, and there is not enough physical processor capacity to run both logical partitions, logical partition 3 receives two more processing units for every additional processing unit that logical partition 2 receives. If logical partitions 2 and 3 both require more processing capacity, and there is enough physical processor capacity to run both logical partitions, logical partition 2 and 3 receive an equal amount of unused capacity. In this situation, their uncapped weights are ignored.

When the firmware is at level FW840, or later, if multiple partitions are assigned to a shared processor pool, the uncapped weight is used as an indicator of how the processor resources must be distributed among the partitions in the shared processor pool with respect to the maximum amount of capacity that can be used by the shared processor pool. For example, logical partition 2 has one virtual processor and an uncapped weight of 100. Logical partition 3 also has one virtual processor, but an uncapped weight of 200. If logical partitions 2 and 3 both require more processing capacity, logical partition 3 receives two additional processing units for every additional processing unit that logical partition 2 receives.

The server distributes unused capacity among all of the uncapped shared processor partitions that are configured on the server, regardless of the shared processor pools to which they are assigned. For example, if you configure logical partition 1 to the default shared processor pool and you configure logical partitions 2 and 3 to a different shared processor pool, all three logical partitions compete for the same unused physical processor capacity in the server, even though they belong to different shared processor pools.

Last updated: Fri, July 05, 2019