This article needs additional citations for verification. (October 2015) (Learn how and when to remove this template message)
HiperDispatch is a workload dispatching feature found in the newest IBM mainframe models (the System z10 and IBM zEnterprise System processors) running recent releases of z/OS. HiperDispatch was introduced in February 2008. Support was added to z/VM in its V6R3 release in July 26, 2013.
One of the engineering challenges with large SMP server designs is to maintain near-linear scalability as the number of CPUs increases. Performance and throughput do not double when doubling the number of processors. There are many overhead factors, including contention for cache and main memory access. These overhead factors become increasingly difficult to mitigate as the number of CPUs increases. The design goal for delivering maximum performance is to minimize those overhead factors. Each new mainframe model supports a higher maximum number of CPUs (up to 64 main processors in a single System z10 mainframe for example), so this engineering challenge becomes ever more important.
HiperDispatch helps address the problem through a combination of hardware features, z/OS dispatching, and the z/OS Workload Manager. In z/OS there may be tasks waiting for processing attention, such as transaction programs. Each task requires frequent access to memory. In a large SMP design such as System z, some CPUs are physically "closer" with faster access to cache memory that might hold supporting data for particular tasks. HiperDispatch exploits this fact and steers tasks to the CPUs most likely to have the fastest access to relevant data already in cache. If that particular CPU is busy, HiperDispatch will, at first, wait for it to finish its other task, even if another less favorable CPU is idle. However, there are limitations to how patient HiperDispatch will be, as governed by Workload Manager goals. If z/OS Workload Manager senses that there's a risk the pending task will miss its service level (responding within a certain number of milliseconds to a user request for example), Workload Manager and HiperDispatch will send the task over to an idle CPU for processing, even if that CPU must fetch data from slower main memory.
HiperDispatch offers very little CPU savings benefit on machines configured with a relatively small number of CPUs. However, the feature does help very significantly as the CPU count increases. IBM mainframe capacity tables (and thus its software pricing) are all based on the assumption that HiperDispatch is active.
The other benefit of HiperDispatch - "parking" logical CPUs so that the number of CPUs on which z/OS dispatches work more closely matches the LPAR's weight - is applicable to even small machine configurations. (The benefit of this is the reduction of the "short engine" effect, making system performance more responsive.
Workload Manager (WLM) must be configured correctly for HiperDispatch to work well. Some mainframe users have latent problems with their WLM goal settings which are only exposed with HiperDispatch, so there is an option to disable HiperDispatch in those cases where mainframe users do not want to correct those issues right away. However, regardless of whether HiperDispatch is on or off, it's important for installations to maintain their WLM policy.
z/OS System Resource Manager (SRM) To configure z/OS System Resource Manager, modify Parmlib-Member IEAOPTxx: HIPERDISPATCH=YES|NO
YES - SRM should turn on HiperDispatch mode. NO - SRM should turn off HiperDispatch mode.
Partitions with more than 64 logical processors at IPL time are forced to run with HIPERDISPATCH=YES. After IPL, LPARs with more than 64 logical processors cannot switch into HIPERDISPATCH=NO. In case of HIPERDISPATCH=YES (z196 and follow-on CPCs), IRD's VARY CPU management is automatically turned off, independent of the "VARYCPU"-specification.
- up to z10-processor: No
- 196 and follow-on CPCs: YES