Por que alguns modelos de CPU da família Intel 6 (Core 2, Pentium M) não são suportados pelo intel_idle?

Enquanto pesquisava os estados de energia da CPU Core 2 (" C-states "), consegui implementar suporte para a maioria dos processadores Intel Core/Core 2 legados. A implementação completa (patch Linux) com todas as informações básicas está documentada aqui.

À medida que acumulava mais informações sobre esses processadores, começou a ficar evidente que os estados C suportados no(s) modelo(s) Core 2 são muito mais complexos do que os dos processadores anteriores e posteriores. Estes são conhecidos como estados C aprimorados (ou " CxE "), que envolvem o pacote, núcleos individuais e outros componentes no chipset (por exemplo, memória). Na época em que o intel_idledriver foi lançado, o código não era particularmente maduro e vários processadores Core 2 foram lançados com suporte C-state conflitante.

Algumas informações interessantes sobre o suporte do Core 2 Solo/Duo C-state foram encontradas neste artigo de 2006 . Isso é em relação ao suporte no Windows, no entanto, indica o suporte robusto de hardware C-state nesses processadores. As informações sobre Kentsfield entram em conflito com o número do modelo real, então acredito que eles estejam se referindo a um Yorkfield abaixo:

...o processador quad-core Intel Core 2 Extreme (Kentsfield) suporta todas as cinco tecnologias de desempenho e economia de energia — Enhanced Intel SpeedStep (EIST), Thermal Monitor 1 (TM1) e Thermal Monitor 2 (TM2), antigo On-Demand Clock Modulação (ODCM), bem como Estados C aprimorados (CxE). Em comparação com os processadores Intel Pentium 4 e Pentium D 600, 800 e 900, que são caracterizados apenas pelo estado Enhanced Halt (C1), esta função foi expandida nos processadores Intel Core 2 (assim como nos processadores Intel Core Solo/Duo) para todos os estados inativos possíveis de um processador, incluindo Stop Grant (C2), Deep Sleep (C3) e Deeper Sleep (C4).

Este artigo de 2008 descreve o suporte para estados C por núcleo em processadores Intel de vários núcleos, incluindo Core 2 Duo e Core 2 Quad (leitura adicional útil em segundo plano foi encontrada neste white paper da Dell ):

Um estado C principal é um estado C de hardware. Existem vários estados ociosos do núcleo, por exemplo, CC1 e CC3. Como sabemos, um processador moderno de última geração possui vários núcleos, como os processadores móveis Core Duo T5000/T7000 lançados recentemente, conhecidos como Penryn em alguns círculos. O que costumávamos pensar como uma CPU / processador, na verdade tem várias CPUs de uso geral. O Intel Core Duo tem 2 núcleos no chip do processador. O Intel Core-2 Quad possui 4 desses núcleos por chip de processador. Cada um desses núcleos tem seu próprio estado ocioso. Isso faz sentido, pois um núcleo pode estar ocioso enquanto outro está trabalhando duro em um thread. Portanto, um estado C principal é o estado ocioso de um desses núcleos.

Encontrei uma apresentação de 2010 da Intel que fornece informações adicionais sobre o intel_idledriver, mas infelizmente não explica a falta de suporte ao Core 2:

Este driver EXPERIMENTAL substitui o acpi_idle nos processadores Intel Atom, processadores Intel Core i3/i5/i7 e processadores Intel Xeon associados. Ele não suporta o processador Intel Core2 ou anterior.

A apresentação acima indica que o intel_idledriver é uma implementação do controlador de CPU "menu", que tem um impacto na configuração do kernel Linux (ou seja, CONFIG_CPU_IDLE_GOV_LADDERvs. CONFIG_CPU_IDLE_GOV_MENU). As diferenças entre os reguladores de escada e de menu são descritas sucintamente nesta resposta .

A Dell tem um artigo útil que lista a compatibilidade de C-state C0 a C6:

Os modos C1 a C3 funcionam basicamente cortando os sinais de clock usados ​​dentro da CPU, enquanto os modos C4 a C6 funcionam reduzindo a voltagem da CPU. Os modos "aprimorados" podem fazer as duas coisas ao mesmo tempo.

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

A partir desta tabela (que mais tarde descobri estar incorreta em alguns casos), parece que havia uma variedade de diferenças no suporte ao estado C com os processadores Core 2 (Observe que quase todos os processadores Core 2 são Socket LGA775, exceto Core 2 Solo SU3500, que é Socket BGA956 e processadores Merom/Penryn. Os processadores "Intel Core" Solo/Duo são um dos Socket PBGA479 ou PPGA478).

Uma exceção adicional à tabela foi encontrada neste artigo :

O Core 2 Duo E8500 da Intel suporta C-states C2 e C4, enquanto o Core 2 Extreme QX9650 não.

Curiosamente, o QX9650 é um processador Yorkfield (família Intel 6, modelo 23, passo 6). Para referência, meu Q9550S ​​é a família Intel 6, modelo 23 (0x17), passo 10, que supostamente suporta C-state C4 (confirmado através de experimentação). Além disso, o Core 2 Solo U3500 tem um CPUID idêntico (família, modelo, stepping) ao Q9550S, mas está disponível em um soquete não LGA775, o que confunde a interpretação da tabela acima.

Claramente, o CPUID deve ser usado pelo menos até o stepping para identificar o suporte de estado C para este modelo de processador e, em alguns casos, pode ser insuficiente (indeterminado neste momento).

A assinatura do método para atribuir informações ociosas da CPU é:

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

Onde modelé enumerado em asm/intel-family.h . Examinando este arquivo de cabeçalho, vejo que os processadores Intel recebem identificadores de 8 bits que parecem corresponder aos números de modelo da família Intel 6:

#define INTEL_FAM6_CORE2_PENRYN 0x17

Do acima, temos Intel Family 6, Model 23 (0x17) definido como INTEL_FAM6_CORE2_PENRYN. Isso deve ser suficiente para definir estados ociosos para a maioria dos processadores Modelo 23, mas pode causar problemas com o QX9650, conforme observado acima.

Assim, minimamente, cada grupo de processadores que possui um conjunto de estados C distinto precisaria ser definido nesta lista.

Zagacki e Ponnala, Intel Technology Journal 12 (3):219-227, 2008 indicam que os processadores Yorkfield de fato suportam C2 e C4. Eles também parecem indicar que a especificação ACPI 3.0a suporta transições apenas entre os estados C C0, C1, C2 e C3, o que presumo que também pode limitar o acpi_idledriver Linux a transições entre esse conjunto limitado de estados C. No entanto, este artigo indica que nem sempre pode ser o caso:

Tenha em mente que é o estado ACPI C, não o do processador, então ACPI C3 pode ser HW C6, etc.

Também digno de nota:

Além do processador em si, como o C4 é um esforço sincronizado entre os principais componentes de silício da plataforma, o chipset Intel Q45 Express alcança uma melhoria de energia de 28%.

O chipset que estou usando é de fato um chipset Intel Q45 Express.

A documentação da Intel sobre os estados do MWAIT é concisa, mas confirma o comportamento ACPI específico do BIOS:

Os estados C específicos do processador definidos nas extensões MWAIT podem mapear para tipos de estado C definidos pela ACPI (C0, C1, C2, C3). A relação de mapeamento depende da definição de um estado C pela implementação do processador e é exposta ao OSPM pelo BIOS usando a tabela _CST definida pela ACPI.

Minha interpretação da tabela acima (combinada com uma tabela da Wikipedia , asm/intel-family.h e os artigos acima) é:

Modelo 9 0x09 ( Pentium M e Celeron M ):

• Banias: C0, C1, C2, C3, C4

Modelo 13 0x0D ( Pentium M e Celeron M ):

• Dothan, Stealey: C0, C1, C2, C3, C4

Modelo 14 0x0E INTEL_FAM6_CORE_YONAH ( Pentium M aprimorado , Celeron M aprimorado ou Intel Core ):

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

Modelo 15 0x0F INTEL_FAM6_CORE2_MEROM (alguns Core 2 e Pentium Dual-Core ):

• Kentsfield, Merom, Conroe, Allendale ( E2xxx/E4xxx e Core 2 Duo E6xxx, T7xxxx/T8xxxx , Core 2 Extreme QX6xxx , Core 2 Quad Q6xxx ): C0, C1, C1E, C2, C2E

Modelo 23 0x17 INTEL_FAM6_CORE2_PENRYN ( Núcleo 2 ):

• Merom-L/Penryn-L: ?
• Penryn ( core 2 Duo móvel de 45 nm ): 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

A partir da quantidade de diversidade no suporte C-state apenas na linha de processadores Core 2, parece que a falta de suporte consistente para C-states pode ter sido a razão para não tentar suportá-los totalmente por meio do intel_idledriver. Eu gostaria de completar totalmente a lista acima para toda a linha Core 2.

Esta não é realmente uma resposta satisfatória, porque me faz pensar quanta energia desnecessária é usada e o excesso de calor foi (e ainda é) gerado por não utilizar totalmente os robustos estados C MWAIT de economia de energia nesses processadores.

Chattopadhyay et al. 2018, Processadores de alto desempenho com eficiência energética: abordagens recentes para projetar computação de alto desempenho verde vale a pena notar para o comportamento específico que estou procurando no chipset Q45 Express:

Estado C do pacote (PC0-PC10) - Quando os domínios de computação, Core e Graphics (GPU) estão ociosos, o processador tem a oportunidade de economia de energia adicional nos níveis uncore e de plataforma, por exemplo, liberando o LLC e limitando a energia do controlador de memória e DRAM IO e, em algum estado, todo o processador pode ser desligado enquanto seu estado é preservado no domínio de energia sempre ativo.

Como teste, inseri o seguinte em linux/drivers/idle/intel_idle.c linha 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 }
};

na intel_idle.clinha 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,
};

na intel_idle.clinha 1073:

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

Após uma rápida compilação e reinicialização dos meus nós PXE, dmesgagora mostra:

[    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

E agora o PowerTOP está mostrando:

          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.

Existe uma maneira mais apropriada de configurar um kernel para suporte ocioso de CPU ideal para esta família de processadores (além de desabilitar o suporte para intel_idle)

Você ativou a ACPI e verificou se acpi_idle está em uso. Eu sinceramente duvido que você tenha perdido alguma opção útil de configuração do kernel. Você sempre pode verificar powertoppossíveis sugestões, mas provavelmente você já sabia disso.

Esta não é uma resposta, mas quero formatá-la :-(.

Observando o código-fonte do kernel, o driver intel_idle atual contém um teste para excluir especificamente a família Intel 6 do driver.

Não, não :-).

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;
}

A ifinstrução não exclui a Família 6. Em vez disso, a ifinstrução fornece uma mensagem quando a depuração está habilitada, informando que essa CPU Intel moderna específica não é suportada pelo intel_idle. Na verdade, minha CPU i5-5300U atual é a Família 6 e usa intel_idle.

O que exclui sua CPU é que não há correspondência na intel_idle_idstabela.

Eu notei este commit que implementou a tabela. O código que ele remove tinha uma switchinstrução em vez disso. Isso facilita ver que o modelo mais antigo intel_idle foi implementado/testado com sucesso/qualquer que seja 0x1A = 26. https://github.com/torvalds/linux/commit/b66b8b9a4a79087dde1b358a016e5c8739ccf186

Eu suspeito que este poderia ser apenas um caso de oportunidade e custo. Quando intel_idlefoi adicionado, parece que o suporte ao Core 2 Duo foi planejado, mas nunca foi totalmente implementado - talvez quando os engenheiros da Intel chegaram a ele, não valeu mais a pena. A equação é relativamente complexa: intel_idleprecisa fornecer benefícios suficientes acpi_idlepara valer a pena suportar aqui, em CPUs que verão o kernel “melhorado” em número suficiente ...

Como a resposta do sourcejedi diz, o driver não exclui toda a família 6. A inicialização verifica CPUs em uma lista de modelos de CPU , cobrindo basicamente todas as microarquiteturas de Nehalem a Kaby Lake. Yorkfield é mais antigo do que isso (e significativamente diferente - Nehalem é muito diferente das arquiteturas que vieram antes dele). O teste da família 6 afeta apenas se a mensagem de erro é impressa; seu efeito é apenas que a mensagem de erro será exibida apenas em CPUs Intel, não em CPUs AMD (a família Intel 6 inclui todas as CPUs Intel não NetBurst desde o Pentium Pro).intel_idle

Para responder à sua pergunta de configuração, você pode desabilitar completamente intel_idle, mas deixá-lo também está bem (contanto que você não se importe com o aviso).

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.