IBM Z9, Planning Manual

Page: 157 / 274

Any other combination of processor definitions is not supported.
Coupling Facility LPs Using Dedicated Central Processors (CPs)
or Dedicated Internal Coupling Facility (ICF) CPs
Important Note
IBM strongly recommends using dedicated CPs or dedicated ICFs for
production coupling facility LPs because coupling facility channel paths and
requests have critical response time requirements. When the coupling facility
is running on a dedicated CP or dedicated ICF CP, an “active wait” polling
algorithm is used to look for coupling facility requests. This results in the
fastest response time and throughput possible for coupling facility requests.
Considerations for Coupling Facilities using Internal Coupling Facility (ICF)
CPs: The following considerations apply to coupling facility LPs that use ICF CPs.
v ICF CPs are managed separately from general purpose CPs. Their presence and
usage does not affect any of the definition or activation rules pertaining to LPs
that use general purpose CPs.
v
ICF CPs will appear in RMF Partition Data reports and other similar reports only
when an LP is activated and assigned to use an ICF CP.
v Non-ICF work is never allowed to be run on an ICF CP. Only PR/SM (to manage
the CP) or a logical partition defined to use ICFs is allowed on the ICF CP.
Coupling Facility LPs Using Shared Central Processors (CPs) or
Shared Internal Coupling Facility (ICF) CPs
Using shared CPs for coupling facility LPs has the following considerations. The
same set of considerations for using shared CPs equally apply to using shared ICF
CPs.
v
You should not cap the processing weights for a coupling facility LP. If you cap
processing weights and you are running a coupling facility, LPAR attempts to
support the cap but may not be successful and the system can be less
responsive.
v A CF with shared CPs may use less CPU resource, but this may come at an
expense to performance. The CF LIC runs in a polling loop so it always looks
busy, even if there is little CF activity. If the CF is sharing a CP with a z/OS
image that has low CPU demands, the CF could use the entire CP. If the CF is
sharing CP(s) with another CF, both will look busy and the CPU resource will be
split between them. For example, if a production CF and a test CF shared a CP
with equal weights, each would only have use of one-half the CP. This would
appear on the RMF CF Usage Summary Report as LOGICAL PROCESSORS:
DEFINED 1 EFFECTIVE 0.5.
Requests to a CF that is sharing a CP may have to wait if another image (z/OS
or CF) is using the shared CP. In fact, the CF’s logical CP may have to wait for
several logical CPs of other partitions to run before it runs again. This has the
net effect of elongating response times. Requests to the CF that could typically
take several microseconds in a dedicated environment can be elongated by
many milliseconds, easily 12.5 to 25 milliseconds or more. If CF response time is
not a consideration (for example, a test CF or a backup CF), the installation can
further limit CF usage of CPU resource by enabling the Dynamic Dispatch option.
This will periodically pause the polling loop. The number and length of the
pauses is determined by the activity in this CF. While this gives more CPU
resource to the other partitions that are sharing the CP, it elongates the service
time in this CF, in most cases, by a considerable amount.
Chapter 3. Determining the Characteristics of Logical Partitions
3-31