[linux][intel]linux对intel c-state和p-state的支持分析

前言： 前文《[qemu][acpi]从虚拟化看ACPI》中，介绍了ACPI的大概逻辑，以及ACPI sleep的S1,S2,S3（STR）,S4（STD），S5状态。 关于节电，intel提供了c-state和p-state的CPU级别的控制，linux也对其进行了支持。 分析： 1,c-state 关于c-state的详细解释，参考intel的文档https://software.intel.com/en-us/articles/power-management-states-p-states-c-states-and-package-c-states

大意是说，intel提供了per-cpu的级别的c-state控制，在不同的控制级别下，级别越深，则越省电，同时也意味着恢复到c0级别需要的时间越多。 结合intel官方的图片：

上面case 1，在一段相对较长的时间内，都比较空闲，隔了一段时间内，出现了下一次的interrupt。 在case 2里面，同样的时间间隔内，出现了多次的指令运行。 因为从c6恢复过来需要的延迟比较高，所以在case 1的情况下，更适合深度c-state。 2,linux对c-state的支持 我们都知道，top看到的cpu使用率里面，idle就是统计cpu执行idle的时间。在kernel中调度的时候，如果发现没有task处于running状态，则会执行idle。idle在执行的时候，可以选择更加深度c-state用来节电。 linux-4.14/drivers/idle/vim intel_idle.c中，定义了多个cpuidle_state结构，对应不同的cpu架构。下图选自haswell架构：

不同级别的c-state对应了不同exit_latency。不同的cpu对c-state的支持也不尽相同。 查询intel SDM或者看这个文件，都可以看出来支持情况。整体来看，越新的架构，支持的越好。 3,intel_idle.max_cstate 默认情况下，会使用最深级别的c-state。对于haswell来说，就是c10。 intel_idle模块提供了一个可配置的参数，在grub的启动参数中可以配置intel_idle.max_cstate=5这样类似的参数即可。 对于cpu密集的延迟敏感型应用来说，可以使用更低的intel_idle.max_cstate配置。intel_idle.max_cstate的默认值是9，如果是0,则表示关闭intel idle。 4,moniotr/mwait 代码linux-4.14/arch/x86/include/asm/mwait.h中，

mwait idle的实现主要由monitor和mwait组合实现的。

monitor函数用asm实现，结合intel SDM：

这里的opcode用byte填写的，可能是asm不支持monitor指令（或者为了兼容低板本的编译器）。即使用monitor来监控idle task的flag。 再来看mwait指令：

使用上文提到的c-state的参数，经过计算，放到eax中，调用mwait指令。

同样也是用byte填写opcode。 综上，结合SDM和上文的monitor参数，可以判断出来：在执行mwait期间，会陷入到c-state（具体的级别和cpu型号，intel_idle.max_cstate有关）中，如果遇到了irq或者idle的flag被修改，则会唤醒cpu。相应irq，或者重新调度。