为什么 intel_idle 不支持某些 Intel family 6 CPU 型号（Core 2、Pentium M）？

在研究 Core 2 CPU 电源状态（“ C-states ”）时，我实际上设法实现了对大多数传统 Intel Core/Core 2 处理器的支持。此处记录了包含所有背景信息的完整实现（Linux 补丁）。

随着我积累了有关这些处理器的更多信息，很明显，Core 2 模型中支持的 C 状态比早期和晚期处理器中的 C 状态要复杂得多。这些被称为增强型 C 状态（或“ CxE ”），它涉及封装、单个内核和芯片组上的其他组件（例如内存）。在intel_idle发布驱动程序时，代码还不是特别成熟，并且已经发布了几个具有冲突 C 状态支持的 Core 2 处理器。

在2006 年的这篇文章中找到了一些关于 Core 2 Solo/Duo C 状态支持的令人信服的信息。这与 Windows 上的支持有关，但它确实表明这些处理器上强大的硬件 C 状态支持。有关肯茨菲尔德的信息与实际型号相冲突，所以我相信他们实际上指的是下面的约克菲尔德：

...四核 Intel Core 2 Extreme (Kentsfield) 处理器支持所有五种性能和节能技术 — 增强型 Intel SpeedStep (EIST)、Thermal Monitor 1 (TM1) 和 Thermal Monitor 2 (TM2)、旧的按需时钟调制 (ODCM) 以及增强型 C 状态 (CxE)。与仅以增强型暂停 (C1) 状态为特征的 Intel Pentium 4 和 Pentium D 600、800 和 900 处理器相比，此功能已在 Intel Core 2 处理器（以及 Intel Core Solo/Duo 处理器）中扩展为处理器的所有可能空闲状态，包括停止授权 (C2)、深度睡眠 (C3) 和深度睡眠 (C4)。

这篇 2008 年的文章概述了对多核 Intel 处理器（包括 Core 2 Duo 和 Core 2 Quad）上的每核 C 状态的支持（在戴尔的这份白皮书中找到了其他有用的背景资料）：

核心 C 状态是硬件 C 状态。有几个核心空闲状态，例如 CC1 和 CC3。众所周知，现代最先进的处理器具有多个内核，例如最近发布的 Core Duo T5000/T7000 移动处理器，在某些圈子中称为 Penryn。我们过去认为的 CPU / 处理器，实际上在其内部有多个通用 CPU。Intel Core Duo 在处理器芯片中有 2 个内核。Intel Core-2 Quad 每个处理器芯片有 4 个这样的内核。这些核心中的每一个都有自己的空闲状态。这是有道理的，因为一个内核可能处于空闲状态，而另一个内核正在努力处理线程。因此，核心 C 状态是其中一个核心的空闲状态。

我找到了一份来自 Intel 的 2010 演示文稿，其中提供了有关驱动程序的一些额外背景intel_idle，但遗憾的是没有解释缺乏对 Core 2 的支持：

此实验性驱动程序取代英特尔凌动处理器、英特尔酷睿 i3/i5/i7 处理器和相关英特尔至强处理器上的 acpi_idle。它不支持 Intel Core2 处理器或更早版本。

上面的介绍确实表明该intel_idle驱动程序是“菜单”CPU 调控器的实现，它对 Linux 内核配置有影响（即CONFIG_CPU_IDLE_GOV_LADDERvs. CONFIG_CPU_IDLE_GOV_MENU）。此答案简明扼要地描述了梯子和菜单管理器之间的区别。

戴尔有一篇有用的文章列出了 C 状态 C0 到 C6 的兼容性：

模式 C1 到 C3 的工作方式基本上是切断 CPU 内部使用的时钟信号，而模式 C4 到 C6 的工作方式是降低 CPU 电压。“增强”模式可以同时进行。

Mode   Name                   CPUs
C0     Operating State        All CPUs
C1     Halt                   486DX4 and above
C1E    Enhanced Halt          All socket LGA775 CPUs
C1E    —                      Turion 64, 65-nm Athlon X2 and Phenom CPUs
C2     Stop Grant             486DX4 and above
C2     Stop Clock             Only 486DX4, Pentium, Pentium MMX, K5, K6, K6-2, K6-III
C2E    Extended Stop Grant    Core 2 Duo and above (Intel only)
C3     Sleep                  Pentium II, Athlon and above, but not on Core 2 Duo E4000 and E6000
C3     Deep Sleep             Pentium II and above, but not on Core 2 Duo E4000 and E6000; Turion 64
C3     AltVID                 AMD Turion 64
C4     Deeper Sleep           Pentium M and above, but not on Core 2 Duo E4000 and E6000 series; AMD Turion 64
C4E/C5 Enhanced Deeper Sleep  Core Solo, Core Duo and 45-nm mobile Core 2 Duo only
C6     Deep Power Down        45-nm mobile Core 2 Duo only

从这个表（我后来发现在某些情况下是不正确的），似乎 Core 2 处理器的 C 状态支持存在各种差异（请注意，几乎所有 Core 2 处理器都是 Socket LGA775，除了 Core 2 Solo SU3500，即Socket BGA956和Merom/Penryn处理器。“Intel Core” Solo/Duo处理器是Socket PBGA479或PPGA478之一）。

在本文中发现了该表的另一个例外：

Intel 的 Core 2 Duo E8500 支持 C 状态 C2 和 C4，而 Core 2 Extreme QX9650 不支持。

有趣的是，QX9650 是 Yorkfield 处理器（Intel family 6，model 23，stepping 6）。作为参考，我的Q9550S是Intel family 6，model 23 (0x17)，stepping 10，据说支持C-state C4（通过实验确认）。此外，Core 2 Solo U3500 具有与 Q9550S 相同的 CPUID（系列、型号、步进），但可用于非 LGA775 插槽，这混淆了对上表的解释。

显然，CPUID 必须至少用于单步执行，以便识别对这种处理器模型的 C 状态支持，并且在某些情况下可能不够（此时未确定）。

分配 CPU 空闲信息的方法签名是：

#define ICPU(model, cpu) \
{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }

在asm/intel-family.hmodel中列举了哪里。检查这个头文件，我发现英特尔 CPU 被分配了 8 位标识符，这些标识符似乎与英特尔家族 6 型号匹配：

#define INTEL_FAM6_CORE2_PENRYN 0x17

综上所述，我们将 Intel Family 6, Model 23 (0x17) 定义为INTEL_FAM6_CORE2_PENRYN. 这应该足以为大多数 Model 23 处理器定义空闲状态，但可能会导致 QX9650 出现上述问题。

因此，至少需要在此列表中定义具有不同 C 状态集的每组处理器。

Zagacki 和 Ponnala，Intel Technology Journal 12 (3):219-227, 2008表明 Yorkfield 处理器确实支持 C2 和 C4。它们似乎还表明 ACPI 3.0a 规范仅支持 C 状态 C0、C1、C2 和 C3 之间的转换，我认为这也可能会限制 Linuxacpi_idle驱动程序在有限的一组 C 状态之间进行转换。但是，这篇文章表明情况可能并非总是如此：

请记住，这是 ACPI C 状态，而不是处理器状态，因此 ACPI C3 可能是 HW C6 等。

另外值得注意的是：

除了处理器本身，由于 C4 是平台中主要硅组件之间的同步工作，英特尔 Q45 Express 芯片组实现了 28% 的功率提升。

我使用的芯片组确实是 Intel Q45 Express 芯片组。

关于 MWAIT 状态的英特尔文档很简洁，但确认了 BIOS 特定的 ACPI 行为：

MWAIT 扩展中定义的特定于处理器的 C 状态可以映射到 ACPI 定义的 C 状态类型（C0、C1、C2、C3）。映射关系取决于处理器实现对 C 状态的定义，并由 BIOS 使用 ACPI 定义的 _CST 表向 OSPM 公开。

我对上表的解释（结合维基百科、asm/intel-family.h和上述文章中的一个表）是：

型号 9 0x09（奔腾 M和赛扬 M）：

• 巴尼亚斯：C0、C1、C2、C3、C4

型号 13 0x0D（奔腾 M和赛扬 M）：

• 多森，斯蒂利：C0、C1、C2、C3、C4

型号 14 0x0E INTEL_FAM6_CORE_YONAH（增强型奔腾 M、增强型赛扬 M或英特尔酷睿）：

• Yonah ( Core Solo , Core Duo ): C0, C1, C2, C3, C4, C4E/C5

型号 15 0x0F INTEL_FAM6_CORE2_MEROM（某些Core 2和Pentium Dual-Core）：

• Kentsfield、Merom、Conroe、Allendale（E2xxx/E4xxx和Core 2 Duo E6xxx、T7xxxx/T8xxxx、Core 2 Extreme QX6xxx、Core 2 Quad Q6xxx）：C0、C1、C1E、C2、C2E

型号 23 0x17 INTEL_FAM6_CORE2_PENRYN（核心 2）：

• Merom-L/Penryn-L: ?
• Penryn ( Core 2 Duo 45-nm mobile ): C0, C1, C1E, C2, C2E, C3, C4, C4E/C5, C6
• Yorkfield ( Core 2 Extreme QX9650 ): C0, C1, C1E, C2E?, C3
• Wolfdale/Yorkfield（Core 2 Quad、C2Q Xeon、Core 2 Duo E5xxx/E7xxx/E8xxx、Pentium Dual-Core E6xxx、Celeron Dual-Core）：C0、C1、C1E、C2、C2E、C3、C4

从仅 Core 2 系列处理器中 C 状态支持的多样性来看，似乎缺乏对 C 状态的一致支持可能是未尝试通过intel_idle驱动程序完全支持它们的原因。我想完整完成整个 Core 2 系列的上述列表。

这并不是一个真正令人满意的答案，因为它让我想知道由于没有充分利用这些处理器上强大的节能MWAIT C 状态，使用了多少不必要的电源，并且已经（并且仍然）产生了过多的热量。

Chattopadhyay等人。2018 年，节能高性能处理器：设计绿色高性能计算的最新方法对于我在 Q45 Express 芯片组中寻找的特定行为值得注意：

包 C 状态 (PC0-PC10) - 当计算域、核心和图形 (GPU) 空闲时，处理器有机会在非核心和平台级别额外节省功耗，例如，刷新 LLC 和电源门控内存控制器和 DRAM IO，在某些状态下，整个处理器可以关闭，而其状态保留在始终开启的电源域中。

作为测试，我在linux/drivers/idle/intel_idle.c第 127 行插入了以下内容：

static struct cpuidle_state conroe_cstates[] = {
    {
        .name = "C1",
        .desc = "MWAIT 0x00",
        .flags = MWAIT2flg(0x00),
        .exit_latency = 3,
        .target_residency = 6,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
    {
        .name = "C1E",
        .desc = "MWAIT 0x01",
        .flags = MWAIT2flg(0x01),
        .exit_latency = 10,
        .target_residency = 20,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
//  {
//      .name = "C2",
//      .desc = "MWAIT 0x10",
//      .flags = MWAIT2flg(0x10),
//      .exit_latency = 20,
//      .target_residency = 40,
//      .enter = &intel_idle,
//      .enter_s2idle = intel_idle_s2idle, },
    {
        .name = "C2E",
        .desc = "MWAIT 0x11",
        .flags = MWAIT2flg(0x11),
        .exit_latency = 40,
        .target_residency = 100,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
    {
        .enter = NULL }
};

static struct cpuidle_state core2_cstates[] = {
    {
        .name = "C1",
        .desc = "MWAIT 0x00",
        .flags = MWAIT2flg(0x00),
        .exit_latency = 3,
        .target_residency = 6,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
    {
        .name = "C1E",
        .desc = "MWAIT 0x01",
        .flags = MWAIT2flg(0x01),
        .exit_latency = 10,
        .target_residency = 20,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
    {
        .name = "C2",
        .desc = "MWAIT 0x10",
        .flags = MWAIT2flg(0x10),
        .exit_latency = 20,
        .target_residency = 40,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
    {
        .name = "C2E",
        .desc = "MWAIT 0x11",
        .flags = MWAIT2flg(0x11),
        .exit_latency = 40,
        .target_residency = 100,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
    {
        .name = "C3",
        .desc = "MWAIT 0x20",
        .flags = MWAIT2flg(0x20) | CPUIDLE_FLAG_TLB_FLUSHED,
        .exit_latency = 85,
        .target_residency = 200,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
    {
        .name = "C4",
        .desc = "MWAIT 0x30",
        .flags = MWAIT2flg(0x30) | CPUIDLE_FLAG_TLB_FLUSHED,
        .exit_latency = 100,
        .target_residency = 400,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
    {
        .name = "C4E",
        .desc = "MWAIT 0x31",
        .flags = MWAIT2flg(0x31) | CPUIDLE_FLAG_TLB_FLUSHED,
        .exit_latency = 100,
        .target_residency = 400,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
    {
        .name = "C6",
        .desc = "MWAIT 0x40",
        .flags = MWAIT2flg(0x40) | CPUIDLE_FLAG_TLB_FLUSHED,
        .exit_latency = 200,
        .target_residency = 800,
        .enter = &intel_idle,
        .enter_s2idle = intel_idle_s2idle, },
    {
        .enter = NULL }
};

在intel_idle.c第 983 行：

static const struct idle_cpu idle_cpu_conroe = {
    .state_table = conroe_cstates,
    .disable_promotion_to_c1e = false,
};

static const struct idle_cpu idle_cpu_core2 = {
    .state_table = core2_cstates,
    .disable_promotion_to_c1e = false,
};

在intel_idle.c第 1073 行：

ICPU(INTEL_FAM6_CORE2_MEROM,  idle_cpu_conroe),
ICPU(INTEL_FAM6_CORE2_PENRYN, idle_cpu_core2),

快速编译并重新启动我的 PXE 节点后，dmesg现在显示：

[    0.019845] cpuidle: using governor menu
[    0.515785] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    0.543404] intel_idle: MWAIT substates: 0x22220
[    0.543405] intel_idle: v0.4.1 model 0x17
[    0.543413] tsc: Marking TSC unstable due to TSC halts in idle states deeper than C2
[    0.543680] intel_idle: lapic_timer_reliable_states 0x2

现在 PowerTOP 显示：

          Package   |            CPU 0
POLL        2.5%    | POLL        0.0%    0.0 ms
C1E         2.9%    | C1E         5.0%   22.4 ms
C2          0.4%    | C2          0.2%    0.2 ms
C3          2.1%    | C3          1.9%    0.5 ms
C4E        89.9%    | C4E        92.6%   66.5 ms

                    |            CPU 1
                    | POLL       10.0%  400.8 ms
                    | C1E         5.1%    6.4 ms
                    | C2          0.3%    0.1 ms
                    | C3          1.4%    0.6 ms
                    | C4E        76.8%   73.6 ms

                    |            CPU 2
                    | POLL        0.0%    0.2 ms
                    | C1E         1.1%    3.7 ms
                    | C2          0.2%    0.2 ms
                    | C3          3.9%    1.3 ms
                    | C4E        93.1%   26.4 ms

                    |            CPU 3
                    | POLL        0.0%    0.7 ms
                    | C1E         0.3%    0.3 ms
                    | C2          1.1%    0.4 ms
                    | C3          1.1%    0.5 ms
                    | C4E        97.0%   45.2 ms

I've finally accessed the Enhanced Core 2 C-states, and it looks like there is a measurable drop in power consumption - my meter on 8 nodes appears to be averaging at least 5% lower (with one node still running the old kernel), but I'll try swapping the kernels out again as a test.

An interesting note regarding C4E support - My Yorktown Q9550S processor appears to support it (or some other sub-state of C4), as evidenced above! This confuses me, because the Intel datasheet on the Core 2 Q9000 processor (section 6.2) only mentions C-states Normal (C0), HALT (C1 = 0x00), Extended HALT (C1E = 0x01), Stop Grant (C2 = 0x10), Extended Stop Grant (C2E = 0x11), Sleep/Deep Sleep (C3 = 0x20) and Deeper Sleep (C4 = 0x30). What is this additional 0x31 state? If I enable state C2, then C4E is used instead of C4. If I disable state C2 (force state C2E) then C4 is used instead of C4E. I suspect this may have something to do with the MWAIT flags, but I haven't yet found documentation for this behavior.

I'm not certain what to make of this: The C1E state appears to be used in lieu of C1, C2 is used in lieu of C2E and C4E is used in lieu of C4. I'm uncertain if C1/C1E, C2/C2E and C4/C4E can be used together with intel_idle or if they are redundant. I found a note in this 2010 presentation by Intel Labs Pittsburgh that indicates the transitions are C0 - C1 - C0 - C1E - C0, and further states:

C1E is only used when all the cores are in C1E

I believe that is to be interpreted as the C1E state is entered on other components (e.g. memory) only when all cores are in the C1E state. I also take this to apply equivalently to the C2/C2E and C4/C4E states (Although C4E is referred to as "C4E/C5" so I'm uncertain if C4E is a sub-state of C4 or if C5 is a sub-state of C4E. Testing seems to indicate C4/C4E is correct). I can force C2E to be used by commenting out the C2 state - however, this causes the C4 state to be used instead of C4E (more work may be required here). Hopefully there aren't any model 15 or model 23 processors that lack state C2E, because those processors would be limited to C1/C1E with the above code.

Also, the flags, latency and residency values could probably stand to be fine-tuned, but just taking educated guesses based on the Nehalem idle values seems to work fine. More reading will be required to make any improvements.

I tested this on a Core 2 Duo E2220 (Allendale), a Dual Core Pentium E5300 (Wolfdale), Core 2 Duo E7400, Core 2 Duo E8400 (Wolfdale), Core 2 Quad Q9550S (Yorkfield) and Core 2 Extreme QX9650, and I have found no issues beyond the afore-mentioned preference for state C2/C2E and C4/C4E.

Not covered by this driver modification:

• The original Core Solo/Core Duo (Yonah, non Core 2) are family 6, model 14. This is good because they supported the C4E/C5 (Enhanced Deep Sleep) C-states but not the C1E/C2E states and would need their own idle definition.

The only issues that I can think of are:

• Core 2 Solo SU3300/SU3500 (Penryn-L) are family 6, model 23 and will be detected by this driver. However, they are not Socket LGA775 so they may not support the C1E Enhanced Halt C-state. Likewise for the Core 2 Solo ULV U2100/U2200 (Merom-L). However, the intel_idle driver appears to choose the appropriate C1/C1E based on hardware support of the sub-states.
• Core 2 Extreme QX9650 (Yorkfield) reportedly does not support C-state C2 or C4. I have confirmed this by purchasing a used Optiplex 780 and QX9650 Extreme processor on eBay. The processor supports C-states C1 and C1E. With this driver modification, the CPU idles in state C1E instead of C1, so there is presumably some power savings. I expected to see C-state C3, but it is not present when using this driver so I may need to look into this further.

I managed to find a slide from a 2009 Intel presentation on the transitions between C-states (i.e., Deep Power Down):

In conclusion, it turns out that there was no real reason for the lack of Core 2 support in the intel_idle driver. It is clear now that the original stub code for "Core 2 Duo" only handled C-states C1 and C2, which would have been far less efficient than the acpi_idle function which also handles C-state C3. Once I knew where to look, implementing support was easy. The helpful comments and other answers were much appreciated, and if Amazon is listening, you know where to send the check.

This update has been committed to github. I will e-mail a patch to the LKML soon.

Update: I also managed to dig up a Socket T/LGA775 Allendale (Conroe) Core 2 Duo E2220, which is family 6, model 15, so I added support for that as well. This model lacks support for C-state C4, but supports C1/C1E and C2/C2E. This should also work for other Conroe-based chips (E4xxx/E6xxx) and possibly all Kentsfield and Merom (non Merom-L) processors.

Update: I finally found some MWAIT tuning resources. This Power vs. Performance writeup and this Deeper C states and increased latency blog post both contain some useful information on identifying CPU idle latencies. Unfortunately, this only reports those exit latencies that were coded into the kernel (but, interestingly, only those hardware states supported by the processor):

# cd /sys/devices/system/cpu/cpu0/cpuidle
# for state in `ls -d state*` ; do echo c-$state `cat $state/name` `cat $state/latency` ; done

c-state0/ POLL 0
c-state1/ C1 3
c-state2/ C1E 10
c-state3/ C2 20
c-state4/ C2E 40
c-state5/ C3 20
c-state6/ C4 60
c-state7/ C4E 100

Update: An Intel employee recently published an article on intel_idle detailing MWAIT states.

是否有更合适的方法来配置内核以获得对该系列处理器的最佳 CPU 空闲支持（除了禁用对 intel_idle 的支持）

您启用了 ACPI，并检查了 acpi_idle 是否正在使用中。我真诚地怀疑您是否错过了任何有用的内核配置选项。您可以随时查看powertop可能的建议，但您可能已经知道这一点。

这不是答案，但我想格式化它:-(。

查看内核源代码，当前的 intel_idle 驱动程序包含一个专门从驱动程序中排除 Intel family 6 的测试。

不，它没有:-)。

id = x86_match_cpu(intel_idle_ids);
if (!id) {
    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
        boot_cpu_data.x86 == 6)
        pr_debug(PREFIX "does not run on family %d model %d\n",
            boot_cpu_data.x86, boot_cpu_data.x86_model);
    return -ENODEV;
}

该if语句不排除 Family 6。相反，该if语句在启用调试时提供一条消息，表明此特定的现代 Intel CPU 不受intel_idle. 事实上，我目前的 i5-5300U CPU 是 Family 6，它使用intel_idle.

不包括您的 CPU 是表中没有匹配intel_idle_ids项。

我注意到这个实现表的提交。它删除的代码有一个switch语句。这很容易看出最早的模型 intel_idle 已经实现/成功测试/无论是 0x1A = 26。 https://github.com/torvalds/linux/commit/b66b8b9a4a79087dde1b358a016e5c8739ccf186

我怀疑这可能只是机会和成本的问题。添加时intel_idle，似乎计划了对 Core 2 Duo 的支持，但从未完全实施——也许当英特尔工程师开始考虑它时，它已经不值得了。这个等式相对复杂：intel_idle需要提供足够的优势acpi_idle，使其值得在这里支持，在 CPU 上将看到足够数量的“改进”内核......

正如sourcejedi的回答所说，驱动程序并不排除所有系列 6。intel_idle初始化检查CPU 型号列表中的 CPU，基本上涵盖了从 Nehalem 到 Kaby Lake 的所有微架构。Yorkfield 比这更老（并且显着不同——Nehalem 与之前的架构非常不同）。family 6测试只影响是否打印错误信息；它的效果只是错误消息只会显示在 Intel CPU，而不是 AMD CPU（Intel family 6 包括自 Pentium Pro 以来的所有非 NetBurst Intel CPU）。

要回答您的配置问题，您可以完全禁用intel_idle，但也可以保留它（只要您不介意警告）。

Another year, less and less of these old machines, but still no kernel support for idle states. I customised a kernel in a similar way to above and got useful drops in core temperature and power use. Previously the core temperatures were around 60C at idle, and around 45C with the custom intel_idle.

I used a slightly different configuration in intel_idle.c. I set the disable C1E promotion flag: C1E is a state that is normally reached automatically (if configured in the BIOS) whenever a processor is put into C1. intel_idle disables this in all cases and treats C1E as a separate C-state, mainly to avoid the processor dropping unexpectedly into a state with a latency that could cause QoS issues (note that this means max_cstate is one higher than you might expect because 2 is C1E). The C2E state is similar, but not disabled or handled separately in intel_idle, so I left it out of the configuration completely. The BIOS usually has an option to enable or disable automatic promotion to this state, so you could disable it in the BIOS, enable it in intel_idle, and possibly get better results but I haven't tried it.

This was on an E2180, so no states higher than C2/C2E, but the main gains seem to come with the first idle state. I have an even older Pentium 4 with Linux support only for C1 and that knocks 10-15C off the core temperature. Experiments with a Core i7 show only marginal extra temperature drops with enabling C3 or C6, although you might think that battery savings are still worth it. I haven't found any noticeable performance issues with the latencies configured as shown above, but it isn't exactly a hardcore gaming machine anyway.