Mientras investigaba los estados de energía de la CPU de Core 2 ("Estados C "), de hecho logré implementar soporte para la mayoría de los procesadores Intel Core/Core 2 heredados. La implementación completa (parche de Linux) con toda la información de fondo se documenta aquí.
A medida que acumulaba más información sobre estos procesadores, se hizo evidente que los estados C compatibles con los modelos Core 2 son mucho más complejos que los de los procesadores anteriores y posteriores. Estos se conocen como estados C mejorados (o "CxE "), que involucran el paquete, los núcleos individuales y otros componentes del conjunto de chips (por ejemplo, la memoria). En ese momento, el intel_idle se lanzó el controlador, el código no estaba particularmente maduro y se lanzaron varios procesadores Core 2 que tenían soporte C-state en conflicto.
En este artículo de 2006 se encontró información convincente sobre la compatibilidad con Core 2 Solo/Duo C-state. Esto está relacionado con la compatibilidad con Windows; sin embargo, indica la robusta compatibilidad con hardware C-state en estos procesadores. La información sobre Kentsfield entra en conflicto con el número de modelo real, por lo que creo que en realidad se refieren a un Yorkfield a continuación:
...el procesador Intel Core 2 Extreme (Kentsfield) de cuatro núcleos es compatible con las cinco tecnologías de rendimiento y ahorro de energía:IntelSpeedStep mejorado (EIST), Thermal Monitor 1 (TM1) y Thermal Monitor 2 (TM2), la antigua modulación de reloj bajo demanda ( ODCM), así como Estados C mejorados (CxE). En comparación con los procesadores Intel Pentium 4 y Pentium D 600, 800 y 900, que se caracterizan únicamente por el estado Enhanced Halt (C1), esta función se ha ampliado en los procesadores Intel Core 2 (así como en los procesadores Intel Core Solo/Duo) para todos los posibles. estados inactivos de un procesador, incluidos Stop Grant (C2), Deep Sleep (C3) y DeeperSleep (C4).
Este artículo de 2008 describe la compatibilidad con los estados C por núcleo en los procesadores Intel de varios núcleos, incluidos Core 2 Duo y Core 2 Quad (en este documento técnico de Dell se encontraron lecturas de antecedentes útiles adicionales):
Un estado C central es un estado C de hardware. Hay varios estados inactivos principales, p. CC1 y CC3. Como sabemos, un procesador moderno de última generación tiene múltiples núcleos, como los procesadores móviles Core DuoT5000/T7000 lanzados recientemente, conocidos como Penryn en algunos círculos. Lo que solíamos considerar como una CPU/procesador, en realidad tiene varias CPU de uso general en su interior. El Intel Core Duo tiene 2 núcleos en el chip del procesador. El Intel Core-2 Quad tiene 4 de estos núcleos por chip de procesador. Cada uno de estos núcleos tiene su propio estado inactivo. Esto tiene sentido ya que un núcleo puede estar inactivo mientras que otro está trabajando duro en un subproceso. Entonces, un estado C central es el estado inactivo de uno de esos núcleos.
Encontré una presentación de 2010 de Intel que brinda información adicional sobre el intel_idle controlador, pero desafortunadamente no explica la falta de soporte para Core 2:
Este controlador EXPERIMENTAL reemplaza a acpi_idle en procesadores Intel Atom, procesadores Intel Core i3/i5/i7 y procesadores Intel Xeon asociados. No es compatible con el procesador Intel Core2 o anterior.
La presentación anterior indica que el intel_idle El controlador es una implementación del gobernador de CPU de "menú", que tiene un impacto en la configuración del kernel de Linux (es decir, CONFIG_CPU_IDLE_GOV_LADDER contra CONFIG_CPU_IDLE_GOV_MENU ). Las diferencias entre los gobernadores de menú y de escalera se describen sucintamente en esta respuesta.
Dell tiene un artículo útil que enumera la compatibilidad C-state C0 a C6:
Los modos C1 a C3 funcionan básicamente cortando las señales de reloj utilizadas dentro de la CPU, mientras que los modos C4 a C6 funcionan reduciendo el voltaje de la CPU. Los modos "mejorados" pueden hacer ambas cosas al mismo tiempo.
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 de esta tabla (que más tarde descubrí que era incorrecta en algunos casos), parece que había una variedad de diferencias en la compatibilidad del estado C con los procesadores Core 2 (tenga en cuenta que casi todos los procesadores Core 2 son Socket LGA775, excepto Core 2 Solo SU3500, que son procesadores Socket BGA956 y Merom/Penryn. Los procesadores "Intel Core" Solo/Duo son uno de Socket PBGA479 o PPGA478).
En este artículo se encontró una excepción adicional a la tabla:
El Core 2 Duo E8500 de Intel es compatible con los estados C C2 y C4, mientras que el Core 2Extreme QX9650 no lo es.
Curiosamente, el QX9650 es un procesador Yorkfield (familia Intel 6, modelo 23, paso 6). Como referencia, mi Q9550S es Intel familia 6, modelo 23 (0x17), paso 10, que supuestamente admite C-state C4 (confirmado mediante experimentación). Además, el Core 2 Solo U3500 tiene un CPUID (familia, modelo, escalonamiento) idéntico al del Q9550S, pero está disponible en un zócalo que no es LGA775, lo que confunde la interpretación de la tabla anterior.
Claramente, el CPUID debe usarse al menos hasta el final para identificar la compatibilidad del estado C con este modelo de procesador y, en algunos casos, puede ser insuficiente (no determinado en este momento).
La firma del método para asignar información de inactividad de la CPU es:
#define ICPU(model, cpu) \
{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
Donde model se enumera en asm/intel-family.h. Al examinar este archivo de encabezado, veo que a las CPU Intel se les asignan identificadores de 8 bits que parecen coincidir con los números de modelo de la familia Intel 6:
#define INTEL_FAM6_CORE2_PENRYN 0x17
De lo anterior, tenemos Intel Family 6, Model 23 (0x17) definido como INTEL_FAM6_CORE2_PENRYN . Esto debería ser suficiente para definir estados inactivos para la mayoría de los procesadores Modelo 23, pero podría causar problemas con QX9650 como se indicó anteriormente.
Entonces, como mínimo, cada grupo de procesadores que tiene un conjunto de estado C distinto debería definirse en esta lista.
Zagacki y Ponnala, Intel Technology Journal acpi_idle de Linux. conductor a las transiciones entre ese conjunto limitado de estados C. Sin embargo, este artículo indica que puede no ser siempre el caso:
Tenga en cuenta que es el estado ACPI C, no el del procesador, por lo que ACPIC3 podría ser HW C6, etc.
También de nota:
Más allá del propio procesador, dado que C4 es un esfuerzo sincronizado entre los principales componentes de silicio de la plataforma, el Intel Q45 ExpressChipset logra una mejora de potencia del 28 por ciento.
El conjunto de chips que estoy usando es de hecho un conjunto de chips Intel Q45 Express.
La documentación de Intel sobre los estados de MWAIT es concisa pero confirma el comportamiento ACPI específico del BIOS:
Los estados C específicos del procesador definidos en las extensiones MWAIT pueden asignarse a tipos de estado C definidos por ACPI (C0, C1, C2, C3). La relación de asignación depende de la definición de un estado C por implementación del procesador y el BIOS la expone a OSPM mediante la tabla _CST definida por ACPI.
Mi interpretación de la tabla anterior (combinada con una tabla de Wikipedia, asm/intel-family.h y los artículos anteriores) es:
Modelo 9 0x09 (Pentium M y Celeron M ):
- Banias:C0, C1, C2, C3, C4
Modelo 13 0x0D (Pentium M y Celeron M ):
- Dothan, Stealey:C0, C1, C2, C3, C4
Modelo 14 0x0E INTEL_FAM6_CORE_YONAH (Pentium M mejorado , Celeron M mejorado o Intel Core ):
- Yonah (Core Solo , Dúo principal ):C0, C1, C2, C3, C4, C4E/C5
Modelo 15 0x0F INTEL_FAM6_CORE2_MEROM (algunos Core 2 y Pentium de doble núcleo ):
- Kentsfield, Merom, Conroe, Allendale (E2xxx/E4xxx y Core 2 Duo E6xxx, T7xxxx/T8xxxx , Core 2 Extremo 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 (móvil Core 2 Duo 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 Dúo E5xxx/E7xxx/E8xxx , Pentium de doble núcleo E6xxx , Celeron de doble núcleo ):C0, C1, C1E, C2, C2E, C3, C4
A partir de la cantidad de diversidad en el soporte de C-state solo dentro de la línea de procesadores Core 2, parece que la falta de soporte consistente para C-states puede haber sido la razón para no intentar admitirlos completamente a través del intel_idle conductor. Me gustaría completar completamente la lista anterior para toda la línea Core 2.
Esta no es realmente una respuesta satisfactoria, porque me hace preguntarme cuánta energía innecesaria se usa y se ha generado (y todavía se genera) un exceso de calor al no utilizar completamente los robustos estados C MWAIT de ahorro de energía en estos procesadores.
Chattopadhyay et al. 2018, Procesadores de alto rendimiento con eficiencia energética:Vale la pena señalar los enfoques recientes para el diseño de computación ecológica de alto rendimiento por el comportamiento específico que busco en el chipset Q45 Express:
Estado C del paquete (PC0-PC10):cuando los dominios de cómputo, el núcleo y los gráficos (GPU) están inactivos, el procesador tiene la oportunidad de ahorrar energía adicional a niveles de plataforma y sin núcleo, por ejemplo, vaciando el LLC y activando el controlador de memoria. y DRAM IO, y en algún estado, todo el procesador se puede apagar mientras su estado se conserva en el dominio de energía siempre encendido.
Como prueba, inserté lo siguiente en linux/drivers/idle/intel_idle.c línea 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 }
};
en intel_idle.c línea 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,
};
en intel_idle.c línea 1073:
ICPU(INTEL_FAM6_CORE2_MEROM, idle_cpu_conroe),
ICPU(INTEL_FAM6_CORE2_PENRYN, idle_cpu_core2),
Después de una rápida compilación y reinicio de mis nodos PXE, dmesg ahora muestra:
[ 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
Y ahora PowerTOP muestra:
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
Finalmente accedí a los estados C de Enhanced Core 2, y parece que hay una caída medible en el consumo de energía:mi medidor en 8 nodos parece tener un promedio de al menos un 5% más bajo (con un nodo que aún ejecuta el kernel anterior) , pero intentaré cambiar los núcleos nuevamente como prueba.
Una nota interesante con respecto a la compatibilidad con C4E:el procesador My Yorktown Q9550S parece admitirlo (o algún otro subestado de C4), como se evidencia arriba. Esto me confunde, porque la hoja de datos de Intel sobre el procesador Core 2 Q9000 (sección 6.2) solo menciona los estados C Normal (C0), HALT (C1 =0x00), HALT extendido (C1E =0x01), Stop Grant (C2 =0x10) , Concesión de parada extendida (C2E =0x11), Dormir/Sueño profundo (C3 =0x20) y Dormir más profundo (C4 =0x30). ¿Qué es este estado 0x31 adicional? Si habilito el estado C2, entonces se usa C4E en lugar de C4. Si deshabilito el estado C2 (forzar el estado C2E), entonces se usa C4 en lugar de C4E. Sospecho que esto puede tener algo que ver con las banderas MWAIT, pero aún no he encontrado documentación para este comportamiento.
No estoy seguro de qué hacer con esto:el estado C1E parece usarse en lugar de C1, C2 se usa en lugar de C2E y C4E se usa en lugar de C4. No estoy seguro si C1/C1E, C2/C2E y C4/C4E se pueden usar junto con intel_idle o si son redundantes. Encontré una nota en esta presentación de 2010 de Intel Labs Pittsburgh que indica que las transiciones son C0 - C1 - C0 - C1E - C0, y otros estados:
C1E solo se usa cuando todos los núcleos están en C1E
Creo que debe interpretarse como que el estado C1E se ingresa en otros componentes (por ejemplo, la memoria) solo cuando todos los núcleos están en el estado C1E. También considero que esto se aplica de manera equivalente a los estados C2/C2E y C4/C4E (aunque C4E se conoce como "C4E/C5", por lo que no estoy seguro de si C4E es un subestado de C4 o si C5 es un subestado). estado de C4E. Las pruebas parecen indicar que C4/C4E es correcto). Puedo forzar el uso de C2E comentando el estado C2; sin embargo, esto hace que se use el estado C4 en lugar de C4E (es posible que se requiera más trabajo aquí). Esperemos que no haya procesadores modelo 15 o modelo 23 que carezcan de estado C2E, porque esos procesadores estarían limitados a C1/C1E con el código anterior.
Además, los valores de las banderas, la latencia y la residencia probablemente podrían ajustarse, pero simplemente hacer conjeturas basadas en los valores inactivos de Nehalem parece funcionar bien. Se requerirá más lectura para realizar mejoras.
Probé esto en un Core 2 Duo E2220 (Allendale), un Dual Core Pentium E5300 (Wolfdale), Core 2 Duo E7400, Core 2 Duo E8400 (Wolfdale), Core 2 Quad Q9550S (Yorkfield) y Core 2 Extreme QX9650, y yo no han encontrado problemas más allá de la preferencia mencionada anteriormente para el estado C2/C2E y C4/C4E.
No cubierto por esta modificación del controlador:
- Los Core Solo/Core Duo originales (Yonah, no Core 2) son la familia 6, modelo 14. Esto es bueno porque admitían los estados C C4E/C5 (Sueño profundo mejorado), pero no los estados C1E/C2E y necesitaría su propia definición inactiva.
Los únicos problemas que se me ocurren son:
- Core 2 Solo SU3300/SU3500 (Penryn-L) son de la familia 6, modelo 23 y serán detectados por este controlador. Sin embargo, no son Socket LGA775, por lo que es posible que no admitan el estado C de Halt mejorado C1E. Lo mismo ocurre con el Core 2 Solo ULV U2100/U2200 (Merom-L). Sin embargo, el
intel_idleEl controlador parece elegir el C1/C1E adecuado en función del soporte de hardware de los subestados. - Al parecer, Core 2 Extreme QX9650 (Yorkfield) no es compatible con C-state C2 o C4. Lo he confirmado comprando un procesador Optiplex 780 y QX9650 Extreme usado en eBay. El procesador admite los estados C C1 y C1E. Con esta modificación del controlador, la CPU permanece inactiva en el estado C1E en lugar de C1, por lo que se supone que se ahorra algo de energía. Esperaba ver C-state C3, pero no está presente al usar este controlador, por lo que es posible que deba investigar esto más a fondo.
Logré encontrar una diapositiva de una presentación de Intel de 2009 sobre las transiciones entre estados C (es decir, Deep Power Down):
En conclusión, resulta que no había una razón real para la falta de compatibilidad con Core 2 en el intel_idle conductor. Ahora está claro que el código auxiliar original para "Core 2 Duo" solo manejaba los estados C C1 y C2, lo que habría sido mucho menos eficiente que el acpi_idle función que también maneja C-estado C3. Una vez que supe dónde buscar, implementar el soporte fue fácil. Los útiles comentarios y otras respuestas fueron muy apreciados, y si Amazon está escuchando, sabrá a dónde enviar el cheque.
Esta actualización se ha enviado a github. Enviaré un parche por correo electrónico a LKML pronto.
Actualizar :También logré desenterrar un Socket T/LGA775 Allendale (Conroe) Core 2 Duo E2220, que es la familia 6, modelo 15, así que también agregué soporte para eso. Este modelo carece de compatibilidad con C-state C4, pero admite C1/C1E y C2/C2E. Esto también debería funcionar para otros chips basados en Conroe (E4xxx/E6xxx) y posiblemente todos los procesadores Kentsfield y Merom (no Merom-L).
Actualizar :Finalmente encontré algunos recursos de ajuste de MWAIT. Este artículo de Power vs. Performance y los estados de Deeper C y la publicación de blog de latencia aumentada contienen información útil sobre cómo identificar las latencias inactivas de la CPU. Desafortunadamente, esto solo informa las latencias de salida que fueron codificadas en el kernel (pero, curiosamente, solo los estados de hardware admitidos por el procesador):
# 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
Actualización: Un empleado de Intel publicó recientemente un artículo sobre intel_idle detallando los estados de MWAIT.
¿Hay alguna forma más adecuada de configurar un núcleo para una compatibilidad inactiva de CPU óptima para esta familia de procesadores (además de desactivar la compatibilidad con intel_idle)
?
Ha habilitado ACPI y ha comprobado que acpi_idle está en uso. Dudo sinceramente que se haya perdido alguna opción útil de configuración del kernel. Siempre puedes marcar powertop para posibles sugerencias, pero probablemente ya lo sabías.
Esta no es una respuesta, pero quiero formatearla :-(.
Mirando el código fuente del kernel, el controlador intel_idle actual contiene una prueba para excluir específicamente a la familia Intel 6 del controlador.
No, no lo hace :-).
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;
}
El if declaración no excluye Family 6. En cambio, el if La declaración proporciona un mensaje cuando la depuración está habilitada, que indica que esta CPU Intel moderna específica no es compatible con intel_idle . De hecho, mi CPU i5-5300U actual es Family 6 y usa intel_idle .
Lo que excluye su CPU es que no hay ninguna coincidencia en el intel_idle_ids mesa.
Noté este compromiso que implementó la tabla. El código que elimina tenía un switch declaración en su lugar. Esto facilita ver que el primer modelo intel_idle se ha implementado/probado con éxito/cualquiera que sea 0x1A =26. https://github.com/torvalds/linux/commit/b66b8b9a4a79087dde1b358a016e5c8739ccf186
Sospecho que esto podría ser solo un caso de oportunidad y costo. Cuando intel_idle se agregó, parece que se planeó la compatibilidad con Core 2 Duo, pero nunca se implementó por completo; tal vez para cuando los ingenieros de Intel lo lograron, ya no valía la pena. La ecuación es relativamente compleja:intel_idle necesita proporcionar suficientes beneficios sobre acpi_idle para que valga la pena apoyarlo aquí, en CPU que verán el núcleo "mejorado" en cantidades suficientes...
Como dice la respuesta de sourcejedi, el controlador no excluye a toda la familia 6. El intel_idle comprobaciones de inicialización de CPU en una lista de modelos de CPU, que cubre básicamente todas las microarquitecturas desde Nehalem hasta Kaby Lake. Yorkfield es más antiguo que eso (y significativamente diferente:Nehalem es muy diferente de las arquitecturas anteriores). La prueba de la familia 6 solo afecta si se imprime el mensaje de error; su efecto es solo que el mensaje de error solo se mostrará en las CPU Intel, no en las CPU AMD (la familia Intel 6 incluye todas las CPU Intel que no son NetBurst desde el Pentium Pro).
Para responder a su pregunta de configuración, puede deshabilitar completamente intel_idle , pero dejarlo también está bien (siempre y cuando no te importe la advertencia).