（以下文章中所说的CPU，如无特别说明，都是传统意义上的CPU，也就是一个物理CPU，一个指令流处理单元）
从IBM POWER4多核开始，IBM的CPU弄得越来越复杂。业界别的厂商也一起煽风点火，加上集成商、销售的大嘴，标书撰写者的有意混淆视听或无意不懂装懂，这CPU是越来越乱了。本文是为了澄清一些事实而写。在写东西之前，先统一概念定义。不同厂商可能有不同的说法，但在这大家先统一一下，免得说来说去被偷换了概念。另外下面的概念多是IBM的概念，别的厂商也应当有类似的名词，请对照使用。
Actived
激活的CPU，IBM通过CUoD License控制，可以让你只使用一部分机器中安装的CPU，这样下次你升级CPU的时候，就不需要硬件更换插拔停机等操作，输入一个激活码，CPU就出来了。
Book
大型机器CPU被一组一组地安装在一个可拆卸模块里面，外面有铁皮保护，插脚也不会是CPU上脆弱而密集的针、点接触，便于维护。通常升级、更换的时候必须以一个book为单位进行。例如这种机型一个book里面是8个CPU，那你就不能购买4个，最少就是8个，或者16个，24个CPU这样去购买。但如果用户需要10个CPU怎么办？那物理采购的还是16个，但通过CUoD激活只激活10个。采购的价格虽然比10个CPU的价值稍多（不会多很多），但是以后升级方便。另外更重要的是CUoD只计算活动CPU的数量，也就是如果在运行过程中，忽然一个CPU坏掉了，只要还有未激活的CPU，就会自动顶替上，始终保证用户可用的CPU数量是10个，避免了因为CPU坏掉而造成的停机（根据坏CPU当时执行的线程有关），如果是用户线程，通常分区不会死掉。但无论多严重的故障，也只是一个分区出问题，别的分区还会照常运行。
Core
这就是一个传统意义的CPU，一个计算单元。之所以叫Core是由于以前集成电路技术不高，一个Core就是一个物理存在的一个集成电路芯片。但现在随着集成电路技术提高，多个CPU被集成到一个芯片内，而人们往往还是对一个芯片叫做一个CPU，所以以前传统意义的CPU就被降格为Core，一个“核心CPU”。
CPU
原始意义的CPU是指计算机的中央处理器，而现在多指一个封装模块，也就是说可能多个中央处理单元连同辅助的协处理器、内存缓存管理器等等只要被封装在一个集成电路芯片里，就被称为一个CPU。
CUoD
Capacity Upgrade on Demand容量按需升级。IBM提出的一种硬件License管理技术，就是购买时多买一些物理资源（CPU，内存等等，通常与只购买使用的CPU、内存相比，额外成本很低），但通过激活码控制，只能使用一部分，当需要的时候，随时购买新的激活码，激活不能使用的CPU和内存，实现升级。
HMT
Hard Multi-Thread 硬件多线程。这里要注意区分多指令和多线程。在CPU里面执行指令，指令仿佛水流一样在流动。对于现代的多任务操作系统而言，同一个时刻，有很多任务（线程）需要处理，即使是多个CPU，也不能满足同时处理线程数的要求。也就是说，系统可能只有4个CPU，但同时要求处理的线程数可能已经达到了100个，每个CPU平均要处理25个。由于一个线程要处理很长时间，甚至属于永不终结的线程，操作系统不能完全处理完一个线程，等其退出再去处理另一个，如果这样，别的线程大概就要等几分钟，甚至几小时，也许永远等不到那一天（如果此线程是无限循环的）。所以操作系统使用的折中的方案，就是每个线程处理一段时间，当此线程暂时不需要CPU或者处理了太长的时间之后，通过分时的方式，把此线程停下来，而去执行另一个线程。这也就是说，通过“软”的方式，实现了多线程处理。由于这是操作系统的软实现方案，每次线程切换都需要执行额外的指令（操作系统指令），因此切换效率比较低。IBM POWER系列CPU从RS64型号之后，就开始支持硬切换了，也就是CPU能够完成指令切换。注意，在CPU这个级别，它根本不知道什么线程不线程的，只能看到一列指令。当指令在执行的时候，很可能会停下来，等待一些辅助操作，例如等待中断、必须的数据或指令不在Cache中，这时候CPU执行的指令流都会中断，而去等待新的指令流接续。HMT技术就是将这个等待时间利用起来，把另一组需要执行的指令调入CPU执行，这样就比以往增加了CPU的利用度，减少CPU空闲时间。
HT
Intel对HMT的称呼，可以说是一种HMT的技术实现。
Installed
安装的物理资源，就是机器里面装的CPU或者内存数量。不过这些资源并不一定全都可用，由于物理故障被deconfig，由于没有买License而没有激活，都会使可用的物理资源数少于安装的资源数。
lcpu
从操作系统看到的可用CPU，又被称为逻辑CPU。从操作系统角度，一个CPU的概念是能够在当时（无需分时等额外处理）处理一条指令流（也就是一个线程）的执行单元。多任务操作系统可以同时并行执行很多线程，但是这种并行并不是严格意义上的并行，而是多CPU并行（这是真正意义上的并行）及分时并行的混合结果。从用户角度看来，如果以1秒钟时长取平均，那么10个CPU，每个CPU花一秒钟执行完1个线程和1个CPU每0.1秒执行完1个线程，总效果都是1秒钟总计执行完10个线程，效果是一样的，但是这两种做法操作系统底层编程显然有区别。精细的考察，多CPU系统线程执行比较“平滑”，但是对于不能进行线程拆分（例如有严格的执行顺序要求）的程序，执行效果较差，因为可能9个CPU闲置，无事可做，而第10个CPU非常忙；单CPU系统“抖动”比较大，在多线程环境响应不太好，对于某个特定的线程而言，偶尔有短暂“死机”感觉（在多任务调度不好的操作系统，或者某个线程有非常高的计算、内存数据移动要求时尤其如此）。在AIX中，使用vmstat命令可以看到，在POWER5,6等支持SMT技术的机型中，lcpu是2倍于proc的数值，这是由于这两种CPU，能够利用SMT技术，单一CPU同时执行两条线程的指令流，看起来好像多了一倍的CPU。
Module DCM, QCM, MCM
多个CPU内核（core）被集成到一个集成电路芯片里，每块这样的集成电路芯片就叫做一个Module，如果是双核芯片，被称为Dual Core Module，4核叫做Quad Core Module，很多个核叫做Multi-Core Module
Pipe Line
CPU的一种设计、实现方式。CPU在处理指令的时候，需要经过取指令、解码指令、处理指令、放置结果等多个子过程，为了提高效率，可以采用流水线作业的方式，一条指令在取指令，前一条已经进入解码阶段，再前一条则正在处理，再之前的一条则已经到了放置结果阶段。通过这种技术，以前一个子过程需要1微秒，4个子过程则需要4微秒，也就是一条CPU指令需要4微秒的时间才能完成。而用流水线技术则1微秒就可以完成一条指令，当然CPU刚启动执行的第一条指令还要等4微秒，不过也仅仅等着一次。其它需要等待的时间是发生了指令跳转（包括指令转移），下一条要执行的指令不一定在什么地方，这样预先取址、解码的指令可能不是下一条要执行的指令，流水线就中断了，需要重新初始化流水线。但无论怎样，大部分指令，例如80%的指令都能顺序下来，流水线的效率还是很高的。另外，CPU设计者引入了其它的办法协助解决这个问题，例如如果解码到的指令是条件指令，会触发取址指令把可能的跳转目的地址的指令都取出来进行解码，这样无论条件判断出来转到那里，指令都已经解码好了，缺点是需要额外的解码单元电路；还有的做法是进行一些“智能”分析，大概估算出跳转的可能，并与编译程序配合，在程序编译的时候就做出适当的组合和特别标志位，协助CPU进行条件跳转的判断。
Physical CPU
与虚拟、逻辑CPU对比而言，一个实实在在能马上执行指令的CPU单元就是物理CPU，其它的虚拟CPU，逻辑CPU则是从高层系统看起来是个CPU，可以执行指令，但指令只是交给了物理CPU硬件，用某种队列方式进行处理，并不能真正立即执行。
Proc
AIX操作系统中看到的CPU，是Processor的简称，可能是一个物理CPU或者通过虚拟化技术虚拟出的虚拟CPU，到底是物理CPU还是虚拟CPU，则根据机型不同。如果是POWER5、6的机型，看到的是虚拟CPU，如果是POWER4或更早的机型，则是物理CPU。虚拟CPU和物理CPU之间有一定的对应关系，请参考Virtual Processor的说明。
Processing Unit
IBM POWER5或6机型的物理CPU被称为Processing Unit，简称PU
Processor
同proc
Socket
同Module，但略有不同。Module一般指一个芯片，而一个Socket可能是一个小电路板，上面焊了几个芯片。
SMT
Simultaneous Multi-Thread。模拟多线程，但这不是用软件模拟，而是硬件CPU本身来“模拟”是POWER5,6 CPU特有的技术。当一个物理CPU单元执行指令的时候，由于在某个瞬间，只是一条指令在执行，而CPU是为了处理各种各样指令而设计，好比是一个加工工厂，同时有车钳铣刨多种设备，但这个工厂每次只加工一个工件，SMT技术则考虑到有很多个加工设备，同时弄进几个工件（指令）进行处理。但这种技术不同于pipe line和super scale，也不同于HMT。可以理解为SMT同时利用了HMT和pipe line/super scale的优点。
pipe line/super scale是指令层面的技术，只对单独的指令流有效，它们看不到线程这么高的层次。而对于线程层次的认知则几乎可以完全避免指令跳转造成的CPU指令流流水线中断，因为两个线程指令之间完全不可能存在相互依存关系，两组指令流之间的执行顺序可以任意调整，绝对不可能冲突；
HMT技术则只处于线程切换层次，与指令层结合的时候不“平滑”，也就是切换的时候要把当前的指令流停下来，或等待当前指令流停下，这样就存在一个短暂的指令中断间隙。虽然这个暂停时间很短，例如只是1，2个时钟周期，但如果频繁发生HMT切换，这个中断时间也不少。
SMT同时利用了两者的优势，通过操作系统内核和CPU的特殊标志寄存器，让CPU在进行指令流调度的时候，把两组线程的指令调配到同一条物理CPU的处理流水线上，这样一来，一个线程在进行加法运算，另一个线程可能需要跳转，它们两者显然使用不同的寄存器进行操作，可以同时被处理，而且不用担心它们两者之间会发生干涉，例如一组指令更新另一组指令的输入结果，这是不可能发生的！因为操作系统对线程的定义就是他们之间没有直接相互关系。线程之间的通信通过更高层的共享内存空间、信号灯等机制完成，其结果就是一条：两组指令流都可以畅快地执行，没有干涉发生。
SMT虽然在指令执行并行性上实现了突破，但并非万能。如果两组指令流在某个时刻都在进行乘法运算，出现了竞争同一个物理CPU寄存器的情况，其中一条指令流还是要停下来的。这时候POWER5,6 CPU使用HMT的能力，一条指令流无中断执行，另一条指令流被硬切换出去，再调入其它线程的指令流。总之，SMT技术使单一物理CPU永远至少能够执行1条以上指令流，最好的情况下能够达到并行两条，平均而言，一般是1.3-5倍的执行效率。在AIX操作系统，为了反映出这个额外的指令流处理能力，使用了逻辑CPU，也就是lcpu的概念。
Super Scale
与Pipe Line技术对应，这是CPU电路设计的另一种方案，在这种方案中，CPU一次取一组指令，进行统一解码、执行。如果完成一条指令需要4微秒，那么只要能同时取4条指令并行处理，则平均1条指令完成时间就变成了1微秒，CPU执行速度大大提高。这种方案同样会遇到条件跳转问题，解决方案与Pipe Line技术类似，例如同时虚拟执行条件跳转的两个（或者多个）目标地址的指令，最后通过条件指令的结果去实际选择到底采用那个分支。当然，这也需要CPU硬件电路、编译系统配合，来提高执行效率。
Virtual Processor/VP
也也是IBM POWER 5,6 CPU引入的技术。这两种CPU能够让操作系统以为有若干物理CPU，但实际上只分配给它们很少一部分物理CPU时间片，只有当有处理要求的时候，才把物理CPU的时间片交过去，执行指令。初始分配时最大的比例是1:10，运转过程中动态分配的比例是1:100。这里面涉及的分配过程稍微复杂一点，我下一节再继续说，看到这时你才能了解你到底有多少CPU，能用多少CPU，是怎么用的。
Way
可以把Way等同于物理CPU，等同于core，等同于Processor Unit/PU
现在我先交代一下分配规则（以下都是针对POWER 5,6的机型的说明，POWER 4及以前的机型，分配了多少物理CPU，就是多少，毫无疑问）。
给一个分区分配的物理CPU可以是0.1到物理机器所有可用的（激活）的物理CPU（Processor Unit / PU）中间的任何数值，小数点后只有1位。如果整机有16颗激活的CPU，则一个分区可以分配的物理CPU可以是0.1，0.8，6.4 .... 15.9到16中的任何数值。这个数值被称为Entitlement的CPU(EC)数。也就是说，对于这个分区，EC的数量是必保的，你可以不使用那么多，但是只要你想用，无论发生什么情况，你一定能拿到这么多。
于此对应，在进行分区的时候还要分配Virtual Processor （VP）。前面说过，VP是给操作系统看的，也就是蒙骗操作系统，让它“认为”你分了多少物理CPU给它。VP数量必须是整数，让操作系统去对用户讲0.1个CPU过于复杂，IBM不想把事情弄得太乱了。另外，既然是虚拟的，那就不能少了，只有你这种大公无私的人才会借给别人5.3元，却对他说：就当我借给你5块好了！IBM不会这么傻，它会告诉操作系统：6块！实际上，更激进一些，它可以让操作系统觉得拥有从6-53中间任何整数的CPU。也就是说，VP最少是圆整后的EC的整数值，最多是10倍的EC/PU。当然，也有上限，就是操作系统（AIX）目前支持的最大CPU个数：64。如果一个物理机器最多物理CPU个数为32，你给一个分区分配了6.4的EC，虽然理论上你可以分配给这个分区64的VP，但超过32的数值没有实际意义，仅可用来作为支持测试。
VP仅仅是虚数，给操作系统炫耀的么？当然不是，它还是有实际意义的，但必须处于uncapped（不封顶）状态下才有效。uncapped也是四个分区CPU资源分配参数之一（到现在，我们有了EC或者叫PU，VP, uncapped，还有另一个weight一会会提到）。如果uncapped参数设定的是no，则VP多少都没用，操作系统最多用到分配的PU就到头了。但如果uncapped，那就可以继续“抢占”，只要别的分区（在同一CPU共享池内）有空闲的PU（分配的EC并未使用100%）；或者物理整机有未分配的PU；或者POWER 6机型有可以“抢占”专属分区（物理CPU不共享）空闲CPU的license（不共享还可以抢占？！IBM还卖这种霸道的License，掉到钱眼里了）。抢占的上限就是VP的个数。因此，一个uncapped的分区，操作系统看起来有VP个“物理CPU”，如果使用传统意义上按CPU数量收费的软件，并且有技术限定，会监视CPU个数，则需要按VP个数购买license（你肯定亏了！）。分区最少可以使用0个物理CPU（其实怎么也是大于0，多少需要一点）；如果别的分区不太忙，或者整机有空闲的物理CPU，则此分区最多可以抢占到VP个物理CPU；如果别的分区也很忙，大家都要抢占，那就看各自的weight，按照weight比例抢占，但无论如何，必保此分区分配的PU，也就是EC，这是别的分区抢不走的。
那么还有一些东西，在做分区的时候，Processor Unit 和 Virtual Processor的min, desire, max有什么关系？这三个参数只和你分区启动时能获得多少物理、虚拟CPU，以及分区运行过程中，可以动态迁移的物理、虚拟CPU的最大、最小数量有关。也就是分区启动是，尽力获得desire的数值，如果不行，则尝试最多能获得多少，只要大于min数值就可以启动分区。分区运行过程中动态迁移CPU资源（物理、虚拟都包括），能移走资源，使分区达到的最小值就是min，不能移走更多。反之，能加进资源，是分区达到的最大值就是max，也不能加进来更多。
你到现在明白你有多少CPU了么？
如果你是好学后进，大概此时还意犹未尽：规则我了解了，但IBM技术上如何实现的呢？看官，您继续耐心坐会。。。
无他，还是时间片技术。当然，着不仅仅是软件技术，更需要硬件技术。具体来说，是两硬加一软。物理CPU本身有能力进行快速线程切换；操作系统知道自己所处的虚拟环境，积极加以配合；特殊的管理硬件（在IBM叫做Hypervisor）有一些寄存器用来保存CPU运行状态，例如PURR，Processor Utilization Resource Register，并可以控制CPU进行强制进程切换。
首先，时间被切成以10ms为单位的小时间片，分区所能使用的时间片通过hypervisor控制进行分配，PURR用来记录时间片的使用情况。奇妙的是，绝对意义上，CPU自己是不知道自己是否繁忙的，因为CPU始终在执行指令，即使没有任何任务可做，CPU也在执行指令----操作系统的管理指令。操作系统的空闲进程会插入一些空指令，这是最基本的空闲标志，CPU看到这些空指令，会毫无疑问地把当前进程转到等待，可惜，空指令实在是太少了，在当今这种复杂的多任务管理系统环境，长时间执行类似x86上0x90操作码的空指令几乎不可能。其实CPU经常是很闲的，不知是执行空指令的时候，因为CPU有太多组件，不是所有的组件都忙得要死，跟一个大公司一样，忙的人忙死，闲的人闲死。CPU还有其他的空闲时候，例如，每当线程进入中断等待、操作系统无可执行队列的时候，此时操作系统主动更新某些特殊的寄存器，才可能让CPU知道，现在不忙了，可以休息了。当然，CPU也可以自我感觉繁忙程度，但是不太准确。典型的情况包括刚才提到的空指令，其它情况包括：长时间CPU都没有使用某些寄存器（或者访问频度很少），都没有进行内存数据访问，没有IO，所有指令都在L1 cache里面等等，这都说明CPU比较闲了。
这两种CPU繁忙的判断方式导致了虚拟化技术的两种不同实现。Intel等采用的是trap-and-emulate，也就是对特殊指令进行捕捉和仿真。在x86一类CPU里面有中断陷入、空操作等等指令（或者指令执行的结果），通过对这一类指令进行捕捉，就可以发现CPU处理暂停的时候。不过这种捕捉太细致，是指令级，会产生大量的指令流content switch，这些都是虚拟化后CPU的额外消耗增加。IBM则是采用操作系统自我认知方案，称为paravirtualization，让操作系统定期执行特殊的系统调用，告诉hypervisor自己现在的状态。这两种方案各有优缺点。Intel的方案对于操作系统没有要求，只要能够在老CPU、系统运行，就可以在新的支持虚拟化的CPU上执行。缺点是虚拟化系统开销较大；IBM的方案需要能支持虚拟化调用的新版本操作系统，自行汇报工作情况，hypervisor就可以很好地安排资源分配，效率更高，但以前版本的操作系统就无法在新虚拟化CPU上运行了。顺便说一句，不仅仅虚拟化，CPU在设计的时候，也可能有电源管理功能，当出现长时间闲置的电路，就可以暂时关闭（或降低）这部分电路的供电系统，降低执行频率等等，这是比指令更底层的技术实现，不用CPU指令干预（当然可以通过设定一定参数干预）。缺点呢？就是当CPU真的需要这部分电路，需要有一个电路启动过程，可能额外消耗几个，甚至几十个时钟周期。无论如何，这些指令级的繁忙程度判断是不准确的，虽然CPU可以根据最近执行的调用中，多少是用户调用，多少是系统调用，多少中断等等数据进行判断，总不如操作系统直截了当告诉Hypervisor。实际上，IBM的Power 5，6CPU也不全依靠操作系统，它是一个混合体，可以说80%依靠操作系统汇报，20%自己统计指令情况。这个百分比是我猜测的，到底算法如何，IBM这时候的嘴巴闭得很严，全无International Big Month的作风。
其次，有了当前物理CPU使用比例，就可以判断给某个分区分配物理CPU的数量，也就是PU的数值，它基于以下几个数据，同样，具体算法大嘴巴也没说全，半遮半掩，我只能在这胡说，您也就胡听好了。
Capped分区，最多分配分区profile设定的EC数量，不能多。但如果物理CPU使用比率低，则可以少分。
UnCapped分区，如果物理CPU使用比率高了，则可以多分PU时间片。多分多少呢？先把在同一个CPU共享池内的必保的都分配掉，假如剩下3.6个PU空闲，而有3个UnCapped分区争夺时间片，每个分区EC的cpu都是1，额外获得多少则要看Weight。
Weight 额外分配PU
分区1 128 3.6*128/(128+255+32)=1.11PU，实际最多可分配CPU 2.11，对应于211个10ms时间片
分区2 255 3.6*255/(128+255+32)=2.21PU，实际最多可分配CPU 3.21，对应于321个10ms时间片
分区3 32 3.6*32/(128+255+32)=0.28PU，实际最多可分配CPU 1.28，对应于128个10ms时间片
最后，10ms的时间片和PU到底是怎么分配的？真正用起来，也不可能用0.1个物理CPU啊？！其实很简单，所谓共享粒度为1/100物理CPU就是10ms的时间片。还是刚才提到的分区，1个物理CPU分为100个10ms的时间片段，那么在下一个1秒内，分区1将获得1+1.11=2.11PU；分区2获得2.21PU；分区3获得1.28PU。那么再进行10ms时间片细分，每个时间片下如果有非0数字，则说明在这个时间片时刻当时会分配物理CPU给此分区：
时间片时刻
1 2 3 4 5。。。10 11 12 13 14。。。 100
--------------------------------------------------------------------------------------------
分区1 2 2 2 2 2。。。2 2 2 2 2。。。 2 累计100个2=200
1 0 0 0 0。。。0 1 0 0 0。。。 1 累计11个1=11
--------------------------------------------------------------------------------------------
分区2 3 3 3 3 3。。。3 3 3 3 3。。。 3 累计100个3=300
0 1 1 0 0。。。0 0 1 1 0。。。 0 累计21个1=21
---------------------------------------------------------------------------------------------
分区3 1 1 1 1 1。。。1 1 1 1 1。。。 1 累计100个1
0 0 0 1 1。。。1 0 0 0 1。。。 0 累计28个1
---------------------------------------------------------------------------------------------
累计 6 6 6 6 6。。。6 6 6 6 6。。。 6 总计660个PU时间片
以上的时间片都是真正的物理CPU时间(PU)，具体分配的时候还有虚拟CPU，即Virtual Processor，在版本稍老一点的AIX（其实都是5.3或6.1，不过TL早一些而已），采用平均分布策略。也就是这些物理时间片会被Virtual Processor均分。还是刚才的分区，假设分区1有10个VP，分区2有5个VP，分区3有20个VP。在每个时间片时刻，操作系统和Power虚拟化Hypervisor会进行物理CPU时间片与虚拟CPU时间片之间的对应。我们单看一个分区，分区1：
时间片时刻1，分区1分得3个CPU时间片，但又10个VP，也就是有10个线程（其实是20个，由于lcpu的原因，为了简化起见，就当10个吧）被执行。但其中只有3个VP能对应到物理CPU，因此只有头3个VP上的线程能运行，别的VP上的线程停工待料。通常，一个线程不可能平平安安地执行完完整的10ms，中间总会有点“事情”发生（例如中断、内存换页等等），其优先级不够，要被踢出去，在进行踢线程这个当口，以前的情况是没有虚拟CPU一说，踢线程就是当前CPU踢的，踢完马上载入下一个线程进来。现在呢，有了虚拟CPU，就如同一个纺纱车间有10台机器，但只有一个人看管，一台机器的问题处理完，上下料这时候，这个人一转身，就到下一台机器前接线头去了。也就是说，虚拟CPU把要干的活都准备好了，转等物理CPU空闲，过来马上就干。由于时间粒度是0.01秒（10ms），为了保证不出现虚拟CPU太多，物理CPU时间片太少，虚拟CPU在长时间内都没有物理CPU时间片对应的问题，Hypervisor在设计的时候就做出了最多1:10的限制，也就是1个物理CPU（PU）最多可以虚拟10个虚拟CPU（VP），这样在0.1秒钟的时间里，即使线程非常繁忙，一个虚拟CPU至少能分到1个10ms时间片。反之，分给VP最多的物理时间片就是分满了，一个VP完完整整对应了一个PU。
了解了以上策略，又引出了一个新问题：在物理CPU一定的情况下，给一个分区分配更多的虚拟CPU好呢，还是更少为好？多少算合适？这个问题和你的体重一样不好回答。你是运动员的体质，每天高强度训练，不是为了比赛，只要身体好，多重都不算重；反之，如果你整日坐在计算机前敲程序，能少还是少一点的好。。。总结一下，如下几方面需要综合考虑（注意，只考虑了运行状态，没有考虑profile里面min，max的等问题）：
1. 分区最大希望能用到多少物理CPU？ VP的数量决定了上限，分配总有个限度。如果物理整机才有16个物理CPU，你分了20的VP干什么？
2. 分区最少会用到多少物理CPU？这一条不太重要，因为不用的PU别的分区会抢占，所以通常只是用来设定profile里面min PU的
3. 分区平均用到多少物理CPU？既然平均用这么多，那么设定EC为这个数值是比较合适的，也就是desire的PU
4. VP当然是大于EC的整数，而根据分区任务量特点，可以是1.5倍，2倍的PU，考虑到1的结果，设定一个相近的数值
5. 操作系统版本决定了VP选择的时候是往大了取，还是往小。如果是比较高的TL，例如5.3 TL07 （忘记了），可以取大点的数值，否则小一点比较好。
对于5的解释是这样的：由于VP和PU进行时间片对应的时候，即使IBM做好了POWER CPU，hypervisor，操作系统的综合考虑，这种时间片切换总是要消耗些CPU cycle的，如果采用平均分配时间片策略，显然不如集中分配时间片策略效率高，不过这就需要操作系统改变策略，将线程尽量排满一个VP再去填充下一个VP，而不是一视同仁，只要有VP就分配一个线程过去。这个策略需要操作系统schedo的新参数vpm_xvcpus（default是0，就是enable的）。如果希望填充更多的VP，则可更改此参数为一个特定值，当然是少于全部VP总数（其实是VP数×2-1，因为在实际应用中，此参数对应的是lcpu，并不是VP），大于VP总数也没用。另一个极端的设置是-1，所有VP大平均。由于系统缺省是尽量填充满VP再去填下一个，因此通过能识别单个CPU繁忙程度的软件，例如topas，将看到1个CPU很忙，别的CPU都闲（topas看到的是lcpu）。
现在你真正知道你有几个CPU了么？
版权归垃圾猪orain所有。
阅读(1035) | 评论(0) | 转发(0) |
