Dynamic Coupling Facility Dispatching and Coupling Thin Interrupts
Coupling facility dispatching behavior on shared-engines is controlled through the dynamic coupling facility dispatching command (DYNDISP) for the coupling facility logical partition.
- DYNDISP=THIN: The coupling facility voluntarily gives up control of the shared coupling facility processor whenever it runs out of work to do, relying on coupling thin interrupts to cause the image to get re-dispatched in a timely fashion when new work (or new signals) arrive at the coupling facility to be processed. This allows efficient sharing and time slicing between the sharing coupling facility images and avoids many latencies inherent in polling-based techniques.
- Coupling Thin Interrupts and Coupling Facility Performance in Shared Processor Environments
- A coupling facility command is received by a shared-engine coupling facility image
- A coupling facility signal is received by a shared-engine CF image (for example, arrival of a coupling facility-to-coupling facility duplexing signal)
-
Completion of a coupling facility signal previously sent by the coupling facility (for example, completion of a coupling facility-to-coupling facility duplexing signal).
The interrupt causes the receiving partition to be dispatched by PR/SM, if it is not already dispatched. This allows the request, signal, or request completion to be recognized and processed in a more timely manner. Once the image is dispatched, existing poll for work logic in both CFCC and z/OS can be used largely as is to locate and process the work. The new interrupt simply expedites the re-dispatching of the partition. When using DYNDISP=THIN, the coupling facility will relinquish the processor as soon as all available pending work has been exhausted (or when PR/SM undispatches it off the shared processor, whichever comes first).
In back-up mode or in certain test configurations, the coupling facility has a very low request rate so it throttles back to very low CP usage. Using DYNDISP=THIN, the requests themselves will drive PR/SM to dispatch the coupling facility as requests arrive at the coupling facility with minimal delay that does not adversely affect the performance of the overall system. Since the coupling facility is not consuming more CP resource than it needs to, you can now set the processor weights for the coupling facility to a value high enough to handle the load if the coupling facility was to take over for a failing primary coupling facility. If the primary coupling facility does fail, the requests can be moved immediately to the back-up coupling facility which can then get the CP resource it needs automatically with properly defined LP weights.
Dynamic coupling facility dispatching is particularly useful in configurations where less than one CP of capacity is needed for use by a coupling facility. To enable dynamic coupling facility dispatching, use the DYNDISP coupling facility control code command. See Coupling facility control code commands.