Lors de la recherche des états d'alimentation du processeur Core 2 ("États C "), j'ai en fait réussi à implémenter la prise en charge de la plupart des anciens processeurs Intel Core/Core 2. L'implémentation complète (correctif Linux) avec toutes les informations de base est documentée ici.
Au fur et à mesure que j'accumulais plus d'informations sur ces processeurs, il est devenu évident que les états C pris en charge dans le ou les modèles Core 2 sont beaucoup plus complexes que ceux des processeurs antérieurs et ultérieurs. Ceux-ci sont connus sous le nom d'états C améliorés (ou "CxE "), qui impliquent le package, les cœurs individuels et d'autres composants sur le chipset (par exemple, la mémoire). Au moment où le intel_idle pilote a été publié, le code n'était pas particulièrement mature et plusieurs processeurs Core 2 avaient été publiés avec une prise en charge conflictuelle de l'état C.
Des informations convaincantes sur la prise en charge de l'état C du Core 2 Solo/Duo ont été trouvées dans cet article de 2006. Cela concerne la prise en charge sous Windows, mais cela indique la prise en charge matérielle robuste de l'état C sur ces processeurs. Les informations concernant Kentsfield sont en conflit avec le numéro de modèle réel, donc je pense qu'ils font en fait référence à un Yorkfield ci-dessous :
... le processeur quadricœur Intel Core 2 Extreme (Kentsfield) prend en charge les cinq technologies de performance et d'économie d'énergie - Enhanced IntelSpeedStep (EIST), Thermal Monitor 1 (TM1) et Thermal Monitor 2 (TM2), ancienne modulation d'horloge à la demande ( ODCM), ainsi que les états C améliorés (CxE). Par rapport aux processeurs Intel Pentium 4 et Pentium D 600, 800 et 900, qui se caractérisent uniquement par l'état d'arrêt amélioré (C1), cette fonction a été étendue aux processeurs Intel Core 2 (ainsi qu'aux processeurs Intel Core Solo/Duo) pour tous les états d'inactivité d'un processeur, y compris Stop Grant (C2), Deep Sleep (C3) et DeeperSleep (C4).
Cet article de 2008 décrit la prise en charge des états C par cœur sur les processeurs Intel multicœurs, y compris les Core 2 Duo et Core 2 Quad (des lectures supplémentaires utiles ont été trouvées dans ce livre blanc de Dell) :
Un état C central est un état C matériel. Il existe plusieurs états d'inactivité principaux, par ex. CC1 et CC3. Comme nous le savons, un processeur moderne à la pointe de la technologie possède plusieurs cœurs, comme les processeurs mobiles Core DuoT5000/T7000 récemment sortis, connus sous le nom de Penryn dans certains cercles. Ce que nous avions l'habitude de considérer comme un CPU / processeur, a en fait plusieurs CPU à usage général à côté. L'Intel Core Duo a 2 cœurs dans la puce du processeur. L'Intel Core-2 Quad dispose de 4 puces par processeur de ce type. Chacun de ces cœurs a son propre état inactif. Cela a du sens car un cœur peut être inactif tandis qu'un autre travaille dur sur un fil. Ainsi, un état C du cœur est l'état inactif de l'un de ces cœurs.
J'ai trouvé une présentation d'Intel de 2010 qui fournit des informations supplémentaires sur le intel_idle pilote, mais n'explique malheureusement pas l'absence de prise en charge du Core 2 :
Ce pilote EXPERIMENTAL remplace acpi_idle sur les processeurs Intel Atom, les processeurs Intel Core i3/i5/i7 et les processeurs Intel Xeon associés. Il ne prend pas en charge le processeur Intel Core2 ou antérieur.
La présentation ci-dessus indique bien que le intel_idle pilote est une implémentation du gouverneur de CPU "menu", qui a un impact sur la configuration du noyau Linux (c'est-à-dire CONFIG_CPU_IDLE_GOV_LADDER vs CONFIG_CPU_IDLE_GOV_MENU ). Les différences entre les gouverneurs d'échelle et de menu sont décrites succinctement dans cette réponse.
Dell a un article utile qui répertorie la compatibilité C-state C0 à C6 :
Les modes C1 à C3 fonctionnent en coupant essentiellement les signaux d'horloge utilisés à l'intérieur du CPU, tandis que les modes C4 à C6 fonctionnent en réduisant la tension du CPU. Les modes "améliorés" peuvent faire les deux en même temps.
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
D'après ce tableau (que j'ai trouvé plus tard incorrect dans certains cas), il semble qu'il y avait une variété de différences dans la prise en charge de l'état C avec les processeurs Core 2 (notez que presque tous les processeurs Core 2 sont Socket LGA775, à l'exception de Core 2 Solo SU3500, c'est-à-dire les processeurs Socket BGA956 et Merom/Penryn. Les processeurs "Intel Core" Solo/Duo sont l'un des Socket PBGA479 ou PPGA478).
Une exception supplémentaire au tableau a été trouvée dans cet article :
Le Core 2 Duo E8500 d'Intel prend en charge les états C C2 et C4, contrairement au Core 2Extreme QX9650.
Fait intéressant, le QX9650 est un processeur Yorkfield (famille Intel 6, modèle 23, stepping 6). Pour référence, mon Q9550S est de la famille Intel 6, modèle 23 (0x17), pas à pas 10, qui est censé prendre en charge le C-state C4 (confirmé par l'expérimentation). De plus, le Core 2 Solo U3500 a un CPUID (famille, modèle, stepping) identique au Q9550S mais est disponible dans un socket non LGA775, ce qui confond l'interprétation du tableau ci-dessus.
De toute évidence, le CPUID doit être utilisé au moins jusqu'au stepping afin d'identifier la prise en charge de l'état C pour ce modèle de processeur, et dans certains cas, cela peut être insuffisant (indéterminé pour le moment).
La signature de la méthode d'attribution des informations d'inactivité du processeur est :
#define ICPU(model, cpu) \
{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
Où model est énuméré dans asm/intel-family.h. En examinant ce fichier d'en-tête, je vois que les processeurs Intel se voient attribuer des identifiants 8 bits qui semblent correspondre aux numéros de modèle de la famille Intel 6 :
#define INTEL_FAM6_CORE2_PENRYN 0x17
De ce qui précède, nous avons Intel Family 6, Model 23 (0x17) défini comme INTEL_FAM6_CORE2_PENRYN . Cela devrait être suffisant pour définir les états d'inactivité de la plupart des processeurs du modèle 23, mais pourrait potentiellement causer des problèmes avec le QX9650, comme indiqué ci-dessus.
Ainsi, au minimum, chaque groupe de processeurs ayant un ensemble d'états C distinct devrait être défini dans cette liste.
Zagacki et Ponnala, Intel Technology Journal 12 (3):219-227, 2008 indiquent que les processeurs Yorkfield prennent effectivement en charge C2 et C4. Ils semblent également indiquer que la spécification ACPI 3.0a ne prend en charge que les transitions entre les états C C0, C1, C2 et C3, ce qui, je suppose, peut également limiter Linux acpi_idle pilote aux transitions entre cet ensemble limité d'états C. Cependant, cet article indique que ce n'est pas toujours le cas :
Gardez à l'esprit qu'il s'agit de l'état ACPI C, pas celui du processeur, donc ACPIC3 peut être HW C6, etc.
A noter également :
Au-delà du processeur lui-même, puisque C4 est un effort synchronisé entre les principaux composants en silicium de la plate-forme, le chipset Intel Q45 Express obtient une amélioration de puissance de 28 %.
Le chipset que j'utilise est bien un chipset Intel Q45 Express.
La documentation Intel sur les états MWAIT est concise mais confirme le comportement ACPI spécifique au BIOS :
Les états C spécifiques au processeur définis dans les extensions MWAIT peuvent correspondre aux types d'état C définis par ACPI (C0, C1, C2, C3). La relation de mappage dépend de la définition d'un état C par l'implémentation du processeur et est exposée à OSPM par le BIOS à l'aide de la table _CST définie par l'ACPI.
Mon interprétation du tableau ci-dessus (combiné avec un tableau de Wikipedia, asm/intel-family.h et les articles ci-dessus) est :
Modèle 9 0x09 (Pentium M et Celeron M ):
- Banias :C0, C1, C2, C3, C4
Modèle 13 0x0D (Pentium M et Celeron M ):
- Dothan, Stealey :C0, C1, C2, C3, C4
Modèle 14 0x0E INTEL_FAM6_CORE_YONAH (Pentium M amélioré , Celeron M amélioré ou Intel Core ):
- Yonah (Core Solo , Core Duo ):C0, C1, C2, C3, C4, C4E/C5
Modèle 15 0x0F INTEL_FAM6_CORE2_MEROM (certains Core 2 et Pentium Dual-Core ):
- Kentsfield, Merom, Conroe, Allendale (E2xxx/E4xxx et Core 2 Duo E6xxx, T7xxxx/T8xxxx , Core 2 Extreme QX6xxx , Core 2 Quad Q6xxx ):C0, C1, C1E, C2, C2E
Modèle 23 0x17 INTEL_FAM6_CORE2_PENRYN (Core 2 ):
- Merom-L/Penryn-L : ?
- Penryn (Core 2 Duo 45 nm pour 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 double cœur E6xxx , Celeron Dual-Core ):C0, C1, C1E, C2, C2E, C3, C4
D'après la diversité de la prise en charge de l'état C au sein de la seule gamme de processeurs Core 2, il semble qu'un manque de prise en charge cohérente des états C peut avoir été la raison pour ne pas tenter de les prendre entièrement en charge via le intel_idle chauffeur. Je souhaite compléter entièrement la liste ci-dessus pour toute la gamme Core 2.
Ce n'est pas vraiment une réponse satisfaisante, car cela me fait me demander quelle quantité d'énergie inutile est utilisée et quelle chaleur excessive a été (et est toujours) générée en n'utilisant pas pleinement les robustes états C MWAIT à économie d'énergie sur ces processeurs.
Chattopadhyay et al. 2018, Energy Efficient High Performance Processors :Recent Approaches for Designing Green High Performance Computing mérite d'être noté pour le comportement spécifique que je recherche dans le chipset Q45 Express :
Package C-state (PC0-PC10) - Lorsque les domaines de calcul, Core et Graphics (GPU) sont inactifs, le processeur a la possibilité d'économiser de l'énergie supplémentaire aux niveaux uncore et de la plate-forme, par exemple, en vidant le LLC et en bloquant l'alimentation du contrôleur de mémoire et DRAM IO, et à un certain état, l'ensemble du processeur peut être éteint tandis que son état est préservé sur le domaine d'alimentation toujours actif.
À titre de test, j'ai inséré ce qui suit à la ligne 127 de linux/drivers/idle/intel_idle.c :
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 ligne 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 ligne 1073 :
ICPU(INTEL_FAM6_CORE2_MEROM, idle_cpu_conroe),
ICPU(INTEL_FAM6_CORE2_PENRYN, idle_cpu_core2),
Après une compilation rapide et un redémarrage de mes nœuds PXE, dmesg affiche maintenant :
[ 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
Et maintenant, PowerTOP s'affiche :
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
J'ai enfin accédé aux états C Enhanced Core 2, et il semble qu'il y ait une baisse mesurable de la consommation d'énergie - mon compteur sur 8 nœuds semble être en moyenne d'au moins 5% inférieur (avec un nœud exécutant toujours l'ancien noyau) , mais je vais réessayer d'échanger les noyaux à titre de test.
Une note intéressante concernant la prise en charge de C4E - Mon processeur Yorktown Q9550S semble la prendre en charge (ou un autre sous-état de C4), comme en témoigne ci-dessus ! Cela me déroute, car la fiche technique Intel sur le processeur Core 2 Q9000 (section 6.2) ne mentionne que les états C Normal (C0), HALT (C1 =0x00), Extended HALT (C1E =0x01), Stop Grant (C2 =0x10) , Accord d'arrêt prolongé (C2E =0x11), Veille/Veille profonde (C3 =0x20) et Veille plus profonde (C4 =0x30). Quel est cet état 0x31 supplémentaire ? Si j'active l'état C2, alors C4E est utilisé à la place de C4. Si je désactive l'état C2 (forcer l'état C2E), alors C4 est utilisé à la place de C4E. Je soupçonne que cela peut avoir quelque chose à voir avec les drapeaux MWAIT, mais je n'ai pas encore trouvé de documentation pour ce comportement.
Je ne sais pas quoi faire de cela :l'état C1E semble être utilisé à la place de C1, C2 est utilisé à la place de C2E et C4E est utilisé à la place de C4. Je ne sais pas si C1/C1E, C2/C2E et C4/C4E peuvent être utilisés avec intel_idle ou s'ils sont redondants. J'ai trouvé une note dans cette présentation de 2010 par Intel Labs Pittsburgh qui indique que les transitions sont C0 - C1 - C0 - C1E - C0, et plus loin :
C1E n'est utilisé que lorsque tous les cœurs sont en C1E
Je crois que cela doit être interprété comme l'état C1E est entré sur d'autres composants (par exemple la mémoire) uniquement lorsque tous les cœurs sont dans l'état C1E. Je considère également que cela s'applique de manière équivalente aux états C2 / C2E et C4 / C4E (bien que C4E soit appelé "C4E / C5", je ne sais donc pas si C4E est un sous-état de C4 ou si C5 est un sous- état de C4E. Les tests semblent indiquer que C4/C4E est correct). Je peux forcer l'utilisation de C2E en commentant l'état C2 - cependant, cela entraîne l'utilisation de l'état C4 à la place de C4E (plus de travail peut être nécessaire ici). Espérons qu'il n'y ait pas de processeurs modèle 15 ou modèle 23 qui manquent d'état C2E, car ces processeurs seraient limités à C1/C1E avec le code ci-dessus.
De plus, les drapeaux, les valeurs de latence et de résidence pourraient probablement être affinés, mais il suffit de prendre des suppositions éclairées basées sur les valeurs d'inactivité de Nehalem semble bien fonctionner. Plus de lecture sera nécessaire pour apporter des améliorations.
J'ai testé cela sur un Core 2 Duo E2220 (Allendale), un Dual Core Pentium E5300 (Wolfdale), un Core 2 Duo E7400, un Core 2 Duo E8400 (Wolfdale), un Core 2 Quad Q9550S (Yorkfield) et un Core 2 Extreme QX9650, et je n'ont trouvé aucun problème au-delà de la préférence mentionnée ci-dessus pour l'état C2/C2E et C4/C4E.
Non couvert par cette modification du pilote :
- Les Core Solo/Core Duo d'origine (Yonah, non Core 2) sont de la famille 6, modèle 14. C'est bien car ils prenaient en charge les états C C4E/C5 (Enhanced Deep Sleep) mais pas les états C1E/C2E et aurait besoin de sa propre définition inactive.
Les seuls problèmes auxquels je peux penser sont :
- Les Core 2 Solo SU3300/SU3500 (Penryn-L) sont de la famille 6, modèle 23 et seront détectés par ce pilote. Cependant, ils ne sont pas Socket LGA775, ils peuvent donc ne pas prendre en charge l'état C C1E Enhanced Halt. De même pour le Core 2 Solo ULV U2100/U2200 (Merom-L). Cependant, le
intel_idlele pilote semble choisir le C1/C1E approprié en fonction de la prise en charge matérielle des sous-états. - Core 2 Extreme QX9650 (Yorkfield) ne prendrait pas en charge l'état C C2 ou C4. Je l'ai confirmé en achetant un processeur Optiplex 780 et QX9650 Extreme d'occasion sur eBay. Le processeur prend en charge les états C C1 et C1E. Avec cette modification du pilote, le processeur est inactif dans l'état C1E au lieu de C1, il y a donc probablement des économies d'énergie. Je m'attendais à voir C-state C3, mais il n'est pas présent lors de l'utilisation de ce pilote, je devrai donc peut-être approfondir la question.
J'ai réussi à trouver une diapositive d'une présentation Intel de 2009 sur les transitions entre les états C (c'est-à-dire Deep Power Down):
En conclusion, il s'avère qu'il n'y avait aucune raison réelle pour le manque de support Core 2 dans le intel_idle chauffeur. Il est clair maintenant que le code stub d'origine pour "Core 2 Duo" ne gérait que les états C C1 et C2, ce qui aurait été beaucoup moins efficace que le acpi_idle fonction qui gère également l'état C C3. Une fois que j'ai su où chercher, la mise en œuvre du support a été facile. Les commentaires utiles et autres réponses ont été très appréciés, et si Amazon écoute, vous savez où envoyer le chèque.
Cette mise à jour a été commitée sur github. J'enverrai bientôt un patch au LKML par e-mail.
Mettre à jour :J'ai également réussi à déterrer un Socket T/LGA775 Allendale (Conroe) Core 2 Duo E2220, qui est de la famille 6, modèle 15, donc j'ai également ajouté le support pour cela. Ce modèle ne prend pas en charge C-state C4, mais prend en charge C1/C1E et C2/C2E. Cela devrait également fonctionner pour d'autres puces basées sur Conroe (E4xxx/E6xxx) et éventuellement tous les processeurs Kentsfield et Merom (non Merom-L).
Mettre à jour :J'ai enfin trouvé des ressources de réglage MWAIT. Cet article sur la puissance par rapport aux performances et cet article de blog sur les états C plus profonds et la latence accrue contiennent tous deux des informations utiles sur l'identification des latences d'inactivité du processeur. Malheureusement, cela ne signale que les latences de sortie qui ont été codées dans le noyau (mais, fait intéressant, uniquement les états matériels pris en charge par le processeur) :
# 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
Mise à jour : Un employé d'Intel a récemment publié un article sur intel_idle détaillant les états MWAIT.
Existe-t-il un moyen plus approprié de configurer un noyau pour une prise en charge optimale de l'inactivité du processeur pour cette famille de processeurs (à part la désactivation de la prise en charge d'intel_idle)
Vous avez activé ACPI et vous avez vérifié que acpi_idle est utilisé. Je doute sincèrement que vous ayez manqué une option de configuration du noyau utile. Vous pouvez toujours vérifier powertop pour d'éventuelles suggestions, mais vous le saviez probablement déjà.
Ce n'est pas une réponse, mais je veux la formater :-(.
En regardant le code source du noyau, le pilote intel_idle actuel contient un test pour exclure spécifiquement la famille Intel 6 du pilote.
Non ce n'est pas le cas :-).
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;
}
Le if n'exclut pas la famille 6. Au lieu de cela, le if L'instruction fournit un message lorsque le débogage est activé, indiquant que ce processeur Intel moderne spécifique n'est pas pris en charge par intel_idle . En fait, mon processeur i5-5300U actuel est de la famille 6 et il utilise intel_idle .
Ce qui exclut votre CPU, c'est qu'il n'y a pas de correspondance dans le intel_idle_ids tableau.
J'ai remarqué ce commit qui a implémenté la table. Le code qu'il supprime avait un switch déclaration à la place. Cela permet de voir facilement que le premier modèle intel_idle a été implémenté/testé avec succès/quel que soit 0x1A =26. https://github.com/torvalds/linux/commit/b66b8b9a4a79087dde1b358a016e5c8739ccf186
Je soupçonne qu'il pourrait s'agir simplement d'une question d'opportunité et de coût. Quand intel_idle a été ajouté, il semble que la prise en charge de Core 2 Duo était prévue, mais elle n'a jamais été entièrement implémentée - peut-être qu'au moment où les ingénieurs d'Intel s'y sont mis, cela n'en valait plus la peine. L'équation est relativement complexe :intel_idle doit fournir des avantages suffisants sur acpi_idle pour que ça vaille la peine d'être supporté ici, sur des CPU qui verront le noyau "amélioré" en nombre suffisant...
Comme le dit la réponse de sourcejedi, le conducteur n'exclut pas toute la famille 6. Le intel_idle l'initialisation vérifie les processeurs dans une liste de modèles de processeurs, couvrant essentiellement toutes les micro-architectures de Nehalem à Kaby Lake. Yorkfield est plus ancien que cela (et significativement différent - Nehalem est très différent des architectures qui l'ont précédé). Le test de la famille 6 affecte uniquement si le message d'erreur est imprimé; son effet est uniquement que le message d'erreur ne s'affichera que sur les processeurs Intel, pas sur les processeurs AMD (la famille Intel 6 comprend tous les processeurs Intel non NetBurst depuis le Pentium Pro).
Pour répondre à votre question de configuration, vous pouvez désactiver complètement intel_idle , mais le laisser est bien aussi (tant que l'avertissement ne vous dérange pas).