6. DATA SOURCES › 6.8 PR/SM LPAR Concepts › 6.8.2 How PR/SM Works

6.8.2 How PR/SM Works

When a partition is defined, its channel paths are assigned
and dedicated.  They cannot be shared by other partitions.
If the partitions are executing SCPs that support the ability
to vary channels offline and online, a channel may be varied
offline in one partition, reassigned to another, and then be
varied online.  However, channel paths can be shared across
multiple logical partitions either using Multiple Image
Facility (MIF), or by defining managed channels in a Dynamic
Channel-Path Management (DCM) environment.

Storage (both central and expanded) is also dedicated; it
cannot be shared between nor accessed in any way by other
partitions.  When PR/SM LPAR was originally introduced, in
order to change a logical partition's storage allocation, it
was necessary to modify the partition definition, deactivate
it, reactivate it, and then re-IPL the partition.  IBM has
subsequently made it possible to reconfigure storage
dynamically.

A partition can be defined with up to the number of physical
processors in the processor complex, minus the total number
of dedicated processors, if any.  Within a single complex it
is possible to mix dedicated and shared processors, assuming
sufficient central processors exist.  For any partition with
more than one defined logical processor, however, all of them
must be dedicated or all must be shared.

The LPAR dispatcher allocates processor resources by
assigning central processors to logical processors as needed
by the active partitions.  If the total demand of active
partitions is less than the total resources of the complex,
there is normally no limit placed on the availability of
central processors to any partition other than the limit
implied by the number of logical processors defined for the
partition:  there can never be more central processors
allocated than the number of defined logical processors.
When demand exceeds supply, however, the dispatcher
prioritizes central processor allocations based on partition
weight values specified when the partitions were defined.
(This weighting can be modified dynamically by an authorized
operator.)

Subsequent to the earliest versions of PR/SM LPAR, IBM added
the option of partition capping.  This option is used to
impose a maximum limit on the amount of dispatch time allowed
for a particular partition, even during periods with no
contention for processor time.  This limit is based on the
processor weights of the active partitions in the same way as
it is done during periods of processor contention.

IBM further enhanced resource management across logical
partitions, by introducing its Intelligent Resource Director
(IRD), running on zSeries models with the z/OS operating
system.

A partition's LP is dispatched by means of time slicing.
Normally, the duration of the time slice is determined
dynamically by the LPAR microcode and is based on the total
number of non-dedicated central processors and the number of
active shared LPs.  The duration of a time slice can range
from a minimum of 12.5 milliseconds (ms) to a theoretical
maximum of 300 ms.  A logical processor will remain
dispatched until either the time slice expires or the SCP
running in the partition attempts to place the LP in the wait
state.  When this happens the central processor will be made
available to another logical processor if one is ready with
work and has a higher processor weight, or for LPAR
management functions.

This control can be overridden by the console operator or
system programmer by means of enabling the wait assist
feature and setting a fixed time slice.  When this is done,
the LPAR dispatcher will not undispatch the LP when it goes
into the wait state, but instead leaves the central processor
under the partition's control for the entire duration of the
time slice.  In addition, if wait assist is enabled, the
processing weights are always in effect, whether or not there
is any processor contention.

A note on terminology:  in IBM and other documentation, two
terms, Wait Assist Enabled/Disabled and Wait Completion
Yes/No are used.  They have the same meaning.  For
simplicity's sake, in this guide we will use the terms Wait
Enabled or Wait Disabled.

PR/SM LPAR resource management exacts a price:  the LPAR
eature itself uses some of the processor resources that it
 is managing and allocating on behalf of the logical
partitions.  This is referred to as LPAR management time.
This "overhead," usually quite small, is directly related to
the ratio of active logical processors to the number of
physical processors under LPAR control and to the logical
processor dispatch rate.

The use of dedicated processors reduces this overhead to as
low as 0.1 percent.  This is so low that in some
circumstances it is possible to use LPAR mode to increase
rather than decrease the throughput of a PR/SM-equipped
complex.  Since the overhead involved in managing,
coordinating, and synchronizing multiple processors by a
single SCP can be substantial, reducing or eliminating
multiple central processors can result in significant savings
of processor resources.  If several workloads currently
supported simultaneously within a single multiple-processor
system can be divided into multiple single-processor logical
partitions with dedicated processors, up to a 10 percent
increase in overall throughput is possible.

An additional advantage of dedicated processors is the
improvement in the utilization of the processors' high speed
cache.  Cache management of dedicated processors continues
uninterrupted.  Dispatching a shared LP causes the physical
processor to experience a brief period when it has to wait
longer for instruction and operand fetching from main memory
until the cache is filled again.

Another way to reduce the LPAR overhead, is to use the LPAR
Vary CPU function of the Intelligent Resource Director.  This
facility allows the Workload Manager (WLM) to dynamically
vary offline unneeded CPUs, maximizing the efficient use of
the available central processor resources.

With the Intelligent Resource Director (IRD), the LPAR
interaction within a CPC is not only driven by the relative
weights of each partition, but also by the LPAR capacity (in
terms of service units) and by the importance of workloads
running in each partition.  The available CPU resources are
now dynamically distributed based on these criterias.

The following sections will introduce the two important
functions of the IRD affecting fundamental measurements of
logical partitions utilization:

    1 - Introduction to LPAR CPU Management
    2 - Introduction to LPAR Soft-Capping