本来，出于我个人的一厢情愿，总觉得像CPU频率这种“最最基本的性能指标”——或者说基础连DIY知识都不需要具备的普通消费者在买电脑或者手机的时候总能理解CPU核心频率所表达的意义。可最近一段时间接连被问了几个问题之后，我觉得在这里很有必要从实际测量上的角度去理解这个CPU频率所表达的含义。
什么是CPU频率？
官方一点的解释是：CPU的频率就是CPU内部时钟每秒的周期数，现代的CPU往往用GHz表达——至少也要用MHz表达。这种说法正确吗？正确！但是——存在问题：这种场景下讲到的CPU频率实际上更像是一个瞬时值，即准实时频率，考虑到目前大多数高性能CPU都允许CPU频率根据当前的工况（忙闲程度、电源状态、温度状态）自行调整CPU频率，那这个瞬时值在不同工况下取样的结果是不是可以代表CPU的频率？或者更极端一点的情况下，CPU进入休眠状态，可以认为TSC为0Hz，则这个时候的频率如何统计？被唤醒的一瞬间，TSC如何统计？
![]()
引用SDM文档中的内容，操作系统在计算CPU频率的时候需要通过性能计数器event counter进行统计，要考虑到CPU进入休眠状态的时间占比。至少说明了这个“CPU的频率并非一个固定的数值”。还有对应的turboboost升频，speedstep降频，功耗墙保护，热保护等一系列可以导致频率变化的可能性。
𝐹𝑟𝑒𝑞=Δ𝑎𝑐𝑜𝑢𝑛𝑡𝑒𝑟Δ𝑚𝑐𝑜𝑢𝑛𝑡𝑒𝑟∗𝑇𝑆𝐶
参考Linux kernel 中对于CPU 频率的计算，实际上这里很明确地沿用了SDM建议的方法，变量名都一致的那种。
![]()
统计法计算的CPU频率有什么问题？
首先，对于CPU频率的实现方式上来讲，CPU的频率是由固定的外频（cpuz采用的术语是“总线速度”）和CPU核心自己的倍频得到的，而外频实际上是固定的（当前普遍采用100MHz外频），也就是说，CPU实际运行的频点只会是 N*100MHz 这种情况，不存在其他的频点。而基于统计法得到的频率，类似求平均的“削峰填谷”特性会出现大量非100N这种频率，甚至出现小数点！![]()
另外就是基于统计的频率计算方式实际上往往伴随着一定的统计误差，加上这个计算的过程动用了除法，误差就会进一步被放大。![]()
上图是我随手在我的机器上抓取的CPU频率，2core 4thread的CPU居然出现了3种不同的工作频率。当然这还不是最离谱的，实际上我碰到的问题更加隐晦一点……一个案例
还是某个热门应用客户发现的问题：两批相同型号的CPU在相同的工况下，新的批号比旧批号的CPU实测频率低了20MHz左右，原值应为2.6GHz。上手这个问题之后，发现测试结果中描述的CPU频率实际上是在“运行某个固定压力脚本的情况下，连续取10组间隔1秒采样到的socket基本平均CPU频率”。而且根据上面的描述这减少的20MHz并不符合N*100MHz这种整数，说明出现的问题是由统计方法带来的，于是我动用了手上最细粒度的微秒级统计工具重新采集了两个数据。![]()
![]()
上图是旧批号的数据，下图为新批号。两张直方图中，横坐标是CPU频率，纵坐标是出现的样本数量（呵呵，我连续采样了12W+组样本，远超测量标准的10组）。图已经非常直观了，也就是说这20MHz的频率“下降”实际上并不是来自于真实频率的不稳定导致，而是来自于0.75GHz附近（其实这个bar是0.8GHz）的那一小撮样本最终导致了平均频率的下降，而早先批号的CPU并不具备这个特征。由于大多数CPU的最低频率其实是设置在800MHz（除开笔记本CPU这种异类），那既然CPU试图将CPU频率降到最低，说明CPU的power governor设定大概率是设置成了‘powersave‘而非常见的’performance‘。多次确认之后，终于认定当时的测试环境确实工作在了’powersave‘模式。调整到合理配置之后，两种结果完全一致。当然，说到这里，我这里用了相对直观的点阵图简单描述一下powersave和performance 两种模式的行为差异，横坐标为CPU core频率，纵坐标为CPU core利用率。颜色越深代表出现的概率越高（不知道上传之后对比度、分辨率会不会打折），此外测试过程中存在一定的噪声，我这里也不特别处理了。![]()
performance mode，大多数情况下，频率出现再2.4，2.5，2.6这几个集中点上，2.6最为明显，包含了大多数CPU利用率的情况。![]()
powersave mode就显得有点抽象了。首先，左上角和右下角有大量空白，或者说左下右上有大量点集中。意味着CPU利用率低的时候大多数CPU频率也较低。其次是大约以60%的cpu利用率划一条水平线，低于此线则频率偏低，甚至大多处于最低的0.8GHz左右，高于此线之后，cpu频率大多处于2.6GHz左右。如果上手就说这个频率的定义是微分和积分的关系，可能显得非常中二，但这个问题暴露了至少我们踩到了统计上的两个问题：局部和全体，样本平均导致的失真，以及测试没有严格控制外部变量的大坑。而该客户坚持认为“测量得到的频率”应该就是规格书上描述的“工作频率”，这不问题就来了呗～一个不算总结的总结
对“CPU频率”这个概念的定义不同，从我个人角度上来看，这个概念已经到了必须要堆砌足够多定语的程度了：啥？你问CPU休眠的情况下频率是多少？如果通过采样计算CPU频率的方法，只要你要读取Event counter，CPU核心自然就被唤醒，那显然就不再是“休眠状态”了！
![]()
为感谢支持，已点赞/分享/赞赏10篇/次以上的朋友，请加微信，进入微信群。我将发放免费加入知识星球的链接。
高阅读量文章
