二十世纪七十年代IBM的第一个分配器（dispatcher）进入了操作系统。到了九十年代，IBM引入了Processor Resource/Systems Manager（PR/SM）Hypervisor，允许用户在同一硬件上以逻辑分区（LPAR）的形式运行一个或多个操作系统。到目前，两个分配器还基本不知道对方的存在。然而，随着z10处理器的到来，IBM让它们缩小了距离。

　　首先，我们说说z10的架构：z10的脑部是由“book”组成，其中四个在CEC（Central Electronic Complex）。每个book包含1到16个处理器单元（PU），以及多个级别的缓存和内存。其中，每个处理器有两个本地的缓存级别（cache level）：L1和L1.5。L2缓存和主内存可被所有book中的每个PU使用。
　　
　　你很可能已经猜到，如果某个工作单元不幸被分配到同一book中的一个不同PU上，会有一些不良后果——失去L1和L1.5缓存。如果操作系统把这份工作分配到不同book中的一个PU上，情况会变得更糟。它不仅需要重建缓存，还必须从其它book获取内存页，这会浪费宝贵的CPU周期。因此，IBM设计了HiperDispatch避免这种资源开销。

　　HiperDispatch与CPU管理

　　在z10之前，CPU管理是“水平的”。z/OS的逻辑处理器（LP）会尽量平均分配工作。PR/SM必须根据技术支持人员设置的weight值分配物理处理器单元。z10和HiperDispatch为我们带来了CPU的“垂直”管理。

　　CPU垂直管理中的LP有三种：

1. Vertical High——LP获得它PU的100%。而且，系统会尽力保持LP和PU的联系以保持缓存命中率。
2. Vertical Medium——LP获得它PU的0%—100%。
3. Vertical Low——LP获得PU的0%。实际上，如果没有任何工作或物理资源不可用的话这类LP就会变为“停止”。如果LPAR需要处理器而且在CEC中有可用空间，那么这类LP会活动起来。

　　z/OS会将LP分为不同的组，尽量使一个工作单元分配到同一个组，希望与物理PU建立密切关系。这种密切关系可以减少在不同book间获取内存的资源耗费。IBM所说的PR/SM“quasi-dedicates”会将vertical high的LP指定到物理处理器，剩下的处理器给vertical medium的LP。PR/SM还为z/OS提供了处理器拓扑，因此操作系统知道PU和book的界限。

　　与以前的旧方法不同的是，z/OS会使vertical high的那些处理器尽量的繁忙，而不再是平均分配工作量。因此，有些LP利用率非常高而其它LP几乎闲置的情况就并不罕见了。

　　那么，HiperDispatch到底有利于哪些类型的工作呢？大致情况是这样：

• 一个book的LPAR和批处理运行情况会大致一样
• 计算密集型的任务会获利很少，因为它们通常是与一个处理器相捆绑的
• 中断和发送比较多的事务型任务会得到一定的效率提升
• 大、多book的LPAR可能会获利最大

　　在执行HiperDispatch之前，IBM还推荐对WLM（Workload Management，即工作负载管理）策略进行重新审视。这样，有些以前属于同一服务类型的工作可能需要分开，比如CICS和WebSphere。IBM有一本白皮书叫做“Planning Considerations for HiperDispatch Mode”，它建议在相对计算密集型的CICS和DB2之上推动高交互性的WebSphere。这本书还很好地解释了各种HiperDispatch定义，以及其它一些相关知识。