SYSTEMS MANAGEMENT TIPS
Using z10 HiperDispatch for vertical CPU management
Robert Crawford, Contributor
11.25.2008
Rating: --- (out of 5)
IBM's first dispatcher went into their operating system when they enabled multiprogramming in the 1970s. In the 90s, IBM introduced the Processor Resource/Systems Manager (PR/SM) Hypervisor, which enabled users to run one or more instances of the operating system as logical partitions (LPAR's) on the same hardware. Up until now the two dispatchers have had little notion that the other existed. With the arrival of z10 processors, however, IBM brought them closer together.
First, a discussion of z10 architecture: The brains of a z10 are organized into "books," up to four of them in a Central Electronic Complex (CEC). Each book contains from 1 to 16 Processor Units (PU's), along with several levels of cache and memory. Two of the cache levels, L1 and L1.5, are local to each processor. The L2 cache and main memory are available to every PU in all the books. The books talk to each other in a star-configured bus.
As you've probably already surmised, there's a penalty to pay for the unlucky unit of work that gets dispatched on a different PU in the same book; it loses the L1 and L1.5 cache. The situation only gets worse when the operating system puts the work on a PU in a different book. Not only does it need to rebuild its cache, but its favorite memory pages must be fetched from the other book, costing precious cycles. IBM designed HiperDispatch to avoid that overhead.
HiperDispatch and CPU management
CPU management before the z10 was "horizontal." That is, z/OS had logical processors (LP's) on which it tried to distribute work evenly. PR/SM, for its part, had to apportion physical processing units (PU's) according to weights set by the technical support staff. z10 and HiperDispatch add the option of "vertical" CPU mana
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
gement.
In vertical CPU management LP's belong to one of three classes:
z/OS arranges the LP's into "affinity groups" and tries to keep a unit of work in the same group in the hopes of building an affinity with a physical PU. The strength of the affinity reduces the overhead of fetching memory between books. PR/SM "quasi-dedicates" (IBM's phrase) designated vertical high LP's to physical processors. Left over processor share is given to vertical medium LP's. PR/SM also supplies z/OS with processor topology so the operating system understands PU and book boundaries.
Another consequence of HiperDispatch is z/OS will try to keep the vertical high processors as busy as possible as opposed to the old way of spreading the work evenly. Therefore, it wouldn't be unusual to see several LP's with very high utilization while a couple others are mostly idle or parked.
What type of work benefits from HiperDispatch? The classic IBM reply pertains; "Your mileage will vary." There are, however, broad outlines:
IBM also recommends a Workload Management (WLM) policy review before implementing HiperDispatch. Some work that formerly belonged in the same service class (e.g, CICS and WebSphere) may need to be broken out. An IBM white paper titled, "Planning Considerations for HiperDispatch Mode" recommends promoting highly interactive WebSphere above relatively CPU-bound CICS and DB2. The same document has a nice explanation of various HiperDispatch definitions along with other chestnuts of wisdom.
ABOUT THE AUTHOR:For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
|
|
|
|
|
|
