写在前面:
Tom's hardware最近发的好文
俗话说解决不了问题就解决发现问题的人
爱买又爱嫌, 是不会去买AMD?
机器翻译加人工润饰,建议直上原文
别帖:Intel 10nm真让人头大：不只频率上不去还不稳定
本文:
Sleepy Intel Ice Lake Xeons Take Longer to Ramp Up Frequency Than Expected
https://www.tomshardware.com/news/
sleepy-intel-ice-lake-xeons-take-longer-to-ramp-up-frequency
翻译:
标题:Intel Ice Lake Xeon花了比预期更长的时间离开休眠
副标:如何解决?别让CPU睡下去
Linux kernal的最新patch（透过Phoronix）指出了英特尔近乎神话般的10nm + Ice
Lake Xeon处理器的一个有趣问题：退出某些睡眠状态后，CPU花费比预期更长的时间才能
恢复正常频率，这将影响性能一致性, 由于“不稳定” 的CPU时钟频率。
这个问题的严重性尚不清楚，但如果没有其他说明，它确实表明了英特尔在Ice Lake
Xeon处理器上的工作仍在继续，尽管存在一些挑战。由于有报导称英特尔的server 时程
再次受到延迟，我们上周联系了该公司，以确认时间表是否仍然按计划进行。该公司回应
说：“我们仍有望在2H20向客户交付10nm Ice Lake。”
我们拭目以待。回到眼前的问题。处理器处于各种C state（休眠），以减少空闲期间的
总体功耗。 C state对每个内核的省电程度不同，最深层的睡眠包括停止内核时钟，刷新
快取和降低电压以最大程度地省电。此外，应用package C state，从而减少CPU package
上由所有内核（例如fabric和uncore）共享的资源的功耗和clock。
注: CPU package = Core + Uncore, 所以有C state和package C state
睡眠状态越深，每个处理器可以节省的电量就越多。但是，从较深的睡眠状态恢复到全速
需要的时间比较浅的睡眠状态要长。根据报告，对于Ice Lake Xeon处理器，某些电源状
态下该过程似乎需要更长的时间。
英特尔“kernal测试机器人”发布了patch并解释了该问题。正如Phoronix所指出的那样
，此修复程式码来自一位英特尔员工，这意味着该公司很可能在自己的测试中遇到了该问
题。该问题的解释如下：
“在ICX平台上，当从比C1E更深/等于C1E的C State唤醒时，CPU频率将缓慢上升。尽管此
功能确实在许多情况下节省了能量，但这也可能导致意外结果。例如，工作负载可能会导
致性能不稳定由于CPU频率的不稳定，另外，当CPU利用率较低时，CPU频率可能无法锁定
为特定水平。
“因此，此修补程式码将禁用C1E auto promotion，并将C1E暴露为单独的idle state，
以便在必要时可以通过sysfs禁用C1E和C6。”
为了解决该问题，系统可以完全禁用C1E和C6状态，从而防止芯片进入较低的睡眠状态。
工程师进一步阐述了这个问题： “除了C1和C1E，C6的退出延迟是通过专用工具测量的。
但是_CST暴露的退出延迟（41us）比我们测量的退出延迟（128us）小得多。这可能是由
于_CST使用从PkgC0 + C6唤醒时的延迟，而不是在测量C6时唤醒的PC6 + C6。因为我
们需要理论上最长的延迟所以选择后者。” 在这里，我们看到问题出在如何测量退出等
待时间（CPU弹回到全速状态所花费的时间），然后暴露给Kernal。 ACPI_CST将C state
资讯传达给Kernal，它列出了处理器处于PkgC0 + C6状态时测得的延迟。这意味着一个或
多个内核可能处于C6睡眠状态，但是其余的package（fabric和uncore）仍在全速（PkgC0
）运作。在这种状态下，core仅需41us即可恢复正常操作。 但是，当处理器进入PkgC6
+ C6状态时，package也会与core一起掉电（PkgC6状态），因此处理器要花更多时间才能
恢复全速。英特尔在这种情况下测出128us的睡眠退出延迟，因此看来Kernal得到了错误
的睡眠退出值。 只是为了了解它与其他Intel处理器有何不同，我们搜索了基于Skylake
的处理器的典型睡眠退出延迟。
我们回顾了去年初由大都会应用科学大学的Vladislav Govtva撰写的有趣的学士论文
[PDF]。他测量了几代不同英特尔处理器的睡眠退出延迟，而在上面我们可以看到他使用
英特尔至强铂金8170M（Skylake）的结果。 Govtva在C6状态下测得的最大唤醒延迟（与
退出延迟相同）约为108us，这比Ice Lake处理器快20us。这里可能涉及不同的测量标准
，但是简单比较数字就知道睡眠退出延迟增加18.5％。 英特尔似乎已通过允许系统在特
定条件下禁用某些睡眠状态来“解决”了该问题，但这很可能只是一个极端情况，不适用
于许多类型的应用场合。我们正在与Intel进行进一步的澄清，但是鉴于Ice Lake尚未正
式发布，因此我们希望不会学到很多东西。 有趣的是，英特尔是否会继续通过磨牙(?)来
调整该参数。 Phoronix认为该patch可以进入下个月开放的Linux 5.9 cycle，但可能会
导致更高的功耗以换取更高的性能。