RMF Logical Partition Interaction
Before the introduction of the PR/SM LPAR environment, the Virtual Machine Facility (VM) was commonly used to run multiple SCPs in a single CPC. LPAR mode makes this possible without the additional VM system control program. The fact that RMF measures and records the activity of all the partitions in a PR/SM LPAR complex simplifies the problems encountered when analyzing MVS activity under VM.
micsrm140
Before the introduction of the PR/SM LPAR environment, the Virtual Machine Facility (VM) was commonly used to run multiple SCPs in a single CPC. LPAR mode makes this possible without the additional VM system control program. The fact that RMF measures and records the activity of all the partitions in a PR/SM LPAR complex simplifies the problems encountered when analyzing MVS activity under VM.
In VM, collecting, synchronizing, and summarizing measurement information from each guest with the measurements from a system-wide VM monitor makes the analysis of this environment extremely challenging. With the LPAR mode measurements from RMF, many, if not all, of the effects of sharing a physical complex among multiple SCPs can be characterized with measurement data from a single source.
Since memory and channel paths are dedicated to individual partitions (except when MIF is used), the analysis of the utilization of these resources is largely unchanged when compared to LPAR operations. The single exception is in the measurements of the activity of the I/O Processor (IOP). These are global to the IOP and, therefore, apply to the sum of the activity of all active partitions. There is no direct way to determine the load on the IOP imposed by a specific partition.
As long as the demand for processor resources is less than the availability of central processors, the activity in one logical partition will have little or no impact on other partitions. It is only during periods of contention for processor resources, or when partition capping is in effect, that inter-partition effects can be expected. With capping, it is the presence of other active partitions, not their level of activity, that limits processor dispatching.
Because the LPAR dispatcher prioritizes access to central processors based on the active partitions' relative weights, the effect of contention or partition capping is less processor time available for a logical partition than it would have had in a non-LPAR complex.
The initial relative share of processor resources available to each partition is controlled by the user. The processing weight for a partition is set when the partition is defined and can be modified for an active partition at any time by the console operator. The actual numeric values are meaningful only when compared to each other. Before being applied, the weight is divided by the number of active logical processors for the partition. The weights are then applied to the sum of the activity of all logical processors active in the partition. Thus, during a period of high contention for processor resources, the sum of the dispatch times for all of the logical processors for a partition with a relative weight of 200 will be twice the sum of the dispatch times of a second partition with a weight of 100.
A partition with fewer logical processors defined will receive a higher proportion of an individual logical processor than a partition with more logical processors defined. For example, assume a triadic CPC with three logical partitions is defined, all with equal relative weights. SYS1 is defined with one logical processor, SYS2 with two LPs, and SYS3 with 3 LPs. During periods of contention, all would accumulate approximately equal amounts of dispatch time. Ignoring the effects of LPAR management time, SYS1's single processor would be 100% dispatched, SYS2's two LPs would each be 50% dispatched, and SYS3's three LPs would each be 33% dispatched.
An important consideration is that the number of logical processors defined for a partition can limit its total processor utilization to a value less than that implied by its relative weight. In other words, if a partition has only one logical processor defined, it can never receive more than 50% of the resources of a dyadic CPC, even if it has a high relative weight as compared to the weights of any other active partition.
Dispatching Frequency
If the time slice is not explicitly specified by the user, it is calculated by the LPAR dispatcher. This dynamically calculated value is not recorded in the type 70 subtype 1 record. Although we know from IBM documentation the formula that is used, a change to the formula would be impossible to detect from the information recorded by RMF. If it does change, any programs or procedures based on the formula will require modification. Since the time-slice value changes only when partitions are activated or deactivated, or when logical processors or central processors are varied online or offline, we can expect this to happen relatively infrequently. However, the length of the dynamically determined time slice is actually a maximum value. Unless a partition is wait-enabled, the time slice for dispatching one of its LPs ends immediately upon an attempt to put the central processor into the wait state.
If the count of the dispatch events were known, it would then be possible to calculate the average time slice, which would likely vary considerably from the dynamic time-slice value. Without this number, it is impossible to quantify some of the effects of logical processor dispatching. This includes the effective slowing of processor execution speed and I/O operations.
Logical Processor Dispatching and Execution Rate
Modern processors have a special high-speed memory cache that allows the fetching of instructions and operands much more quickly than is possible from main memory. A cache management algorithm analyzes memory accesses and attempts to satisfy a significant proportion of future memory accesses from the cache rather than from main memory. When the cache is empty, it takes time for the cache manager to analyze access patterns and fill the cache. During this period, the processor is effectively slowed because instructions and operands are fetched from main memory, which takes more machine cycles than fetching from cache.
Each time a central processor is redispatched as a logical processor, the cache is effectively empty because the contents do not reflect recent memory accesses. If the number of processor dispatches were known, it would be possible to estimate the effect on processor speed.
Logical Processor Dispatching and I/O Operations
I/O operations are prioritized in a manner similar to processor weighting. Although the exact details of this process are not documented, this prioritization is at least partially based on the processor shares and on the relative success of the LPAR dispatcher in accurately allocating the central processor resources among competing partitions. If two partitions are given equal weight, the one that is a little "behind" will receive higher priority than the one that is a little "ahead." This means that an I/O interrupt for a partition with a higher priority may cause the central processor to switch away from a lower priority partition to process the interrupt. This will obviously have a detrimental effect on the lower priority partition. In addition, this switching effectively increases the rate of LP dispatching, causing processor cache to be less effectively managed and slowing the effective instruction execution rate.
Unfortunately, no mechanism exists for measuring this effective lengthening of the I/O service time. Although the queue, pending, connect, and disconnect times are accumulated for each device measured by RMF, the actual time it takes an I/O operation to complete may be in excess of the sum of these values if LPAR dispatching causes a delay in processing an interrupt.
If the average time-slice value were available, it would be possible to estimate the effects. By using the duration of the measurement interval, the sum of the dispatch times, the number of dispatches, and the average real I/O service time of a device, the probability that an I/O operation would be delayed and the average duration of the delay could be calculated.