Während der Erforschung der CPU-Leistungszustände von Core 2 ("C-Zustände "), habe ich es tatsächlich geschafft, die Unterstützung für die meisten älteren Intel Core/Core 2-Prozessoren zu implementieren. Die vollständige Implementierung (Linux-Patch) mit allen Hintergrundinformationen ist hier dokumentiert.
Als ich mehr Informationen über diese Prozessoren sammelte, begann sich herauszustellen, dass die in den Core 2-Modellen unterstützten C-States weitaus komplexer sind als die in früheren und späteren Prozessoren. Diese werden als Enhanced C-States bezeichnet (oder "CxE "), die das Gehäuse, einzelne Kerne und andere Komponenten auf dem Chipsatz (z. B. Speicher) betreffen. Zur Zeit der 03 Treiber veröffentlicht wurde, war der Code nicht besonders ausgereift und es wurden mehrere Core 2-Prozessoren veröffentlicht, die widersprüchliche C-State-Unterstützung hatten.
Einige überzeugende Informationen zur C-State-Unterstützung von Core 2 Solo/Duo wurden in diesem Artikel aus dem Jahr 2006 gefunden. Dies bezieht sich auf die Unterstützung unter Windows, weist jedoch auf die robuste Hardware-C-State-Unterstützung auf diesen Prozessoren hin. Die Informationen zu Kentsfield stehen im Widerspruch zur tatsächlichen Modellnummer, daher glaube ich, dass sie sich tatsächlich auf ein Yorkfield unten beziehen:
...der Intel Core 2 Extreme (Kentsfield) Quad-Core-Prozessor unterstützt alle fünf Leistungs- und Energiespartechnologien — Enhanced IntelSpeedStep (EIST), Thermal Monitor 1 (TM1) und Thermal Monitor 2 (TM2), alte On-Demand Clock Modulation ( ODCM) sowie Enhanced C States (CxE). Im Vergleich zu Intel Pentium 4 und Pentium D 600, 800 und 900 Prozessoren, die sich nur durch den Enhanced Halt (C1) State auszeichnen, wurde diese Funktion bei Intel Core 2 Prozessoren (sowie Intel Core Solo/Duo Prozessoren) um alles mögliche erweitert Leerlaufzustände eines Prozessors, einschließlich Stop Grant (C2), Deep Sleep (C3) und DeeperSleep (C4).
Dieser Artikel aus dem Jahr 2008 umreißt die Unterstützung für C-Zustände pro Kern auf Intel-Prozessoren mit mehreren Kernen, einschließlich Core 2 Duo und Core 2 Quad (zusätzliche hilfreiche Hintergrundlektüre finden Sie in diesem Whitepaper von Dell):
Ein Kern-C-Zustand ist ein Hardware-C-Zustand. Es gibt mehrere Core-Ruhezustände, z.B. CC1 und CC3. Wie wir wissen, hat ein moderner State-of-the-Art-Prozessor mehrere Kerne, wie die kürzlich veröffentlichten Core DuoT5000/T7000-Mobilprozessoren, die in manchen Kreisen als Penryn bekannt sind. Was wir früher als CPU / Prozessor betrachteten, enthält tatsächlich mehrere Allzweck-CPUs. Der Intel Core Duo hat 2 Kerne im Prozessorchip. Der Intel Core-2 Quad hat 4 solcher Kerne pro Prozessorchip. Jeder dieser Kerne hat seinen eigenen Ruhezustand. Dies ist sinnvoll, da ein Kern im Leerlauf sein kann, während ein anderer hart an einem Thread arbeitet. Ein Kern-C-Zustand ist also der Ruhezustand eines dieser Kerne.
Ich habe eine Präsentation von Intel aus dem Jahr 2010 gefunden, die zusätzliche Hintergrundinformationen zu 18 enthält Treiber, erklärt aber leider nicht die fehlende Unterstützung für Core 2:
Dieser EXPERIMENTELLE Treiber ersetzt acpi_idle auf Intel AtomProzessoren, Intel Core i3/i5/i7 Prozessoren und zugehörigen Intel XeonProzessoren. Der Intel Core2-Prozessor oder frühere Versionen werden nicht unterstützt.
Die obige Darstellung weist darauf hin, dass 22 Treiber ist eine Implementierung des „Menü“-CPU-Governors, der sich auf die Konfiguration des Linux-Kernels auswirkt (d. h. 35 vs. 47 ). Die Unterschiede zwischen Leiter- und Menüreglern werden in dieser Antwort kurz beschrieben.
Dell hat einen hilfreichen Artikel, der die Kompatibilität von C-State C0 zu C6 auflistet:
Die Modi C1 bis C3 funktionieren, indem sie im Grunde die in der CPU verwendeten Taktsignale unterbrechen, während die Modi C4 bis C6 durch die Reduzierung der CPU-Spannung funktionieren. "Erweiterte" Modi können beides gleichzeitig tun.
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
Aus dieser Tabelle (die sich später in einigen Fällen als falsch herausstellte) geht hervor, dass es bei den Core 2-Prozessoren eine Vielzahl von Unterschieden bei der C-State-Unterstützung gab (beachten Sie, dass fast alle Core 2-Prozessoren Sockel LGA775 sind, mit Ausnahme von Core 2 Solo SU3500, das sind Sockel BGA956 und Merom/Penryn-Prozessoren. "Intel Core" Solo/Duo-Prozessoren sind einer der Sockel PBGA479 oder PPGA478).
Eine weitere Ausnahme von der Tabelle wurde in diesem Artikel gefunden:
Der Core 2 Duo E8500 von Intel unterstützt die C-Zustände C2 und C4, während der Core 2Extreme QX9650 dies nicht tut.
Interessanterweise ist der QX9650 ein Yorkfield-Prozessor (Intel-Familie 6, Modell 23, Stepping 6). Als Referenz ist mein Q9550S Intel-Familie 6, Modell 23 (0x17), Stepping 10, das angeblich C-State C4 unterstützt (durch Experimente bestätigt). Darüber hinaus hat der Core 2 Solo U3500 eine identische CPUID (Familie, Modell, Stepping) wie der Q9550S, ist aber in einem Nicht-LGA775-Sockel erhältlich, was die Interpretation der obigen Tabelle verwirrt.
Natürlich muss die CPUID mindestens bis zum Stepping verwendet werden, um die C-State-Unterstützung für dieses Prozessormodell zu identifizieren, und in einigen Fällen kann dies unzureichend sein (derzeit unbestimmt).
Die Methodensignatur zum Zuweisen von CPU-Leerlaufinformationen lautet:
#define ICPU(model, cpu) \
{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
Wobei 54 ist in asm/intel-family.h aufgeführt. Beim Untersuchen dieser Header-Datei sehe ich, dass Intel-CPUs 8-Bit-Identifikatoren zugewiesen sind, die mit den Modellnummern der Intel-Familie 6 übereinstimmen:
#define INTEL_FAM6_CORE2_PENRYN 0x17
Von oben haben wir Intel Family 6, Modell 23 (0x17), definiert als 67 . Dies sollte zum Definieren von Leerlaufzuständen für die meisten Prozessoren des Modells 23 ausreichen, könnte jedoch möglicherweise Probleme mit dem QX9650 verursachen, wie oben erwähnt.
Daher müsste zumindest jede Gruppe von Prozessoren, die einen bestimmten C-State-Satz hat, in dieser Liste definiert werden.
Zagacki und Ponnala, Intel Technology Journal 12 (3):219-227, 2008 weisen darauf hin, dass Yorkfield-Prozessoren tatsächlich C2 und C4 unterstützen. Sie scheinen auch darauf hinzudeuten, dass die ACPI 3.0a-Spezifikation nur Übergänge zwischen den C-Zuständen C0, C1, C2 und C3 unterstützt, was meiner Meinung nach auch den Linux-74 einschränken könnte Treiber zu Übergängen zwischen diesem begrenzten Satz von C-Zuständen. Dieser Artikel weist jedoch darauf hin, dass dies möglicherweise nicht immer der Fall ist:
Denken Sie daran, dass dies der ACPI-C-Zustand ist, nicht der des Prozessors, also könnte ACPIC3 HW C6 usw. sein.
Auch zu beachten:
Über den Prozessor selbst hinaus erreicht der Intel Q45 ExpressChipsatz eine 28-prozentige Leistungssteigerung, da C4 eine synchronisierte Anstrengung zwischen den wichtigsten Siliziumkomponenten in der Plattform ist.
Der von mir verwendete Chipsatz ist tatsächlich ein Intel Q45 Express Chipsatz.
Die Intel-Dokumentation zu MWAIT-Zuständen ist knapp, bestätigt aber das BIOS-spezifische ACPI-Verhalten:
Die in MWAIT-Erweiterungen definierten prozessorspezifischen C-Zustände können ACPI-definierten C-Zustandstypen (C0, C1, C2, C3) zugeordnet werden. Die Zuordnungsbeziehung hängt von der Definition eines C-Zustands durch die Prozessorimplementierung ab und wird OSPM vom BIOS unter Verwendung der ACPI-definierten _CST-Tabelle offengelegt.
Meine Interpretation der obigen Tabelle (kombiniert mit einer Tabelle aus Wikipedia, asm/intel-family.h und den obigen Artikeln) ist:
Modell 9 0x09 (Pentium M und Celeron M ):
- Banias:C0, C1, C2, C3, C4
Modell 13 0x0D (Pentium M und Celeron M ):
- Dothan, Stealey:C0, C1, C2, C3, C4
Modell 14 0x0E INTEL_FAM6_CORE_YONAH (Enhanced Pentium M , Enhanced Celeron M oder Intel Core ):
- Yonah (Core Solo , Core Duo ):C0, C1, C2, C3, C4, C4E/C5
Modell 15 0x0F INTEL_FAM6_CORE2_MEROM (einige Core 2 und Pentium Dual-Core ):
- Kentsfield, Merom, Conroe, Allendale (E2xxx/E4xxx und Core 2 Duo E6xxx, T7xxxx/T8xxxx , Core 2 Extreme QX6xxx , Core 2 Quad Q6xxx ):C0, C1, C1E, C2, C2E
Modell 23 0x17 INTEL_FAM6_CORE2_PENRYN (Kern 2 ):
- Merom-L/Penryn-L:?
- Penryn (Core 2 Duo 45-nm-Mobilgerät ):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
Aus der Vielfalt der C-State-Unterstützung allein innerhalb der Core 2-Prozessorlinie geht hervor, dass ein Mangel an konsistenter Unterstützung für C-States der Grund dafür gewesen sein könnte, dass nicht versucht wurde, sie vollständig über den 85
Dies ist keine wirklich zufriedenstellende Antwort, da ich mich frage, wie viel unnötiger Strom verbraucht und überschüssige Wärme erzeugt wurde (und immer noch wird), indem die robusten, stromsparenden MWAIT-C-Zustände auf diesen Prozessoren nicht vollständig genutzt werden.
Chattopadhyay et al. 2018, Energy Efficient High Performance Processors:Recent Approaches for Designing Green High Performance Computing ist erwähnenswert für das spezifische Verhalten, nach dem ich im Q45 Express-Chipsatz suche:
Paket C-Zustand (PC0–PC10) – Wenn die Rechendomänen, der Kern und die Grafik (GPU) im Leerlauf sind, hat der Prozessor die Möglichkeit, zusätzliche Energieeinsparungen auf Uncore- und Plattformebene zu erzielen, z. B. durch Leeren des LLC und Power-Gating des Speichercontrollers und DRAM IO, und in einem bestimmten Zustand kann der gesamte Prozessor ausgeschaltet werden, während sein Zustand im Bereich der ständig eingeschalteten Stromversorgung beibehalten wird.
Als Test habe ich in linux/drivers/idle/intel_idle.c Zeile 127 Folgendes eingefügt:
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 }
};
bei 90 Zeile 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,
};
bei 108 Zeile 1073:
ICPU(INTEL_FAM6_CORE2_MEROM, idle_cpu_conroe),
ICPU(INTEL_FAM6_CORE2_PENRYN, idle_cpu_core2),
Nach einem schnellen Kompilieren und Neustarten meiner PXE-Knoten, 117 zeigt jetzt:
[ 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
Und jetzt zeigt 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
Ich habe endlich auf die Enhanced Core 2 C-States zugegriffen, und es sieht so aus, als ob der Stromverbrauch messbar gesunken ist - mein Messgerät auf 8 Knoten scheint im Durchschnitt mindestens 5 % niedriger zu sein (wobei auf einem Knoten noch der alte Kernel ausgeführt wird). , aber ich werde versuchen, die Kernel testweise noch einmal auszutauschen.
Ein interessanter Hinweis zur C4E-Unterstützung - Mein Yorktown Q9550S-Prozessor scheint dies (oder einen anderen Unterzustand von C4) zu unterstützen, wie oben gezeigt! Das verwirrt mich, weil das Intel-Datenblatt zum Core 2 Q9000-Prozessor (Abschnitt 6.2) nur die C-States Normal (C0), HALT (C1 =0x00), Extended HALT (C1E =0x01), Stop Grant (C2 =0x10) erwähnt. , Extended Stop Grant (C2E =0x11), Sleep/Deep Sleep (C3 =0x20) und Deeper Sleep (C4 =0x30). Was ist dieser zusätzliche 0x31-Zustand? Wenn ich den Zustand C2 aktiviere, wird C4E anstelle von C4 verwendet. Wenn ich Zustand C2 deaktiviere (Zustand C2E erzwingen), wird C4 anstelle von C4E verwendet. Ich vermute, dass dies etwas mit den MWAIT-Flags zu tun hat, aber ich habe noch keine Dokumentation für dieses Verhalten gefunden.
Ich bin mir nicht sicher, was ich davon halten soll:Der C1E-Zustand scheint anstelle von C1 verwendet zu werden, C2 wird anstelle von C2E verwendet und C4E wird anstelle von C4 verwendet. Ich bin mir nicht sicher, ob C1/C1E, C2/C2E und C4/C4E zusammen mit 126 verwendet werden können oder wenn sie überflüssig sind. Ich habe in dieser Präsentation von Intel Labs Pittsburgh aus dem Jahr 2010 eine Notiz gefunden, die angibt, dass die Übergänge C0 - C1 - C0 - C1E - C0 sind, und weitere Angaben:
C1E wird nur verwendet, wenn sich alle Kerne in C1E befinden
Ich glaube, das ist so zu interpretieren, dass der C1E-Zustand auf anderen Komponenten (z. B. Speicher) nur dann eingenommen wird, wenn alle Kerne im C1E-Zustand sind. Ich nehme an, dass dies auch für die C2/C2E- und C4/C4E-Zustände gilt (obwohl C4E als "C4E/C5" bezeichnet wird, bin ich mir also nicht sicher, ob C4E ein Unterzustand von C4 ist oder ob C5 ein Unterzustand ist). Status von C4E. Tests scheinen anzuzeigen, dass C4/C4E korrekt ist). Ich kann die Verwendung von C2E erzwingen, indem ich den C2-Zustand auskommentiere - dies führt jedoch dazu, dass der C4-Zustand anstelle von C4E verwendet wird (hier ist möglicherweise mehr Arbeit erforderlich). Hoffentlich gibt es keine Prozessoren der Modelle 15 oder 23, denen der Status C2E fehlt, da diese Prozessoren mit dem obigen Code auf C1/C1E beschränkt wären.
Auch die Flags, die Latenz und die Residency-Werte könnten wahrscheinlich verfeinert werden, aber nur fundierte Vermutungen basierend auf den Nehalem-Idle-Werten zu treffen, scheint gut zu funktionieren. Um Verbesserungen vorzunehmen, ist mehr Lektüre erforderlich.
Ich habe dies auf einem Core 2 Duo E2220 (Allendale), einem Dual Core Pentium E5300 (Wolfdale), einem Core 2 Duo E7400, einem Core 2 Duo E8400 (Wolfdale), einem Core 2 Quad Q9550S (Yorkfield) und einem Core 2 Extreme QX9650 und mir getestet haben keine Probleme gefunden, die über die oben erwähnte Präferenz für die Zustände C2/C2E und C4/C4E hinausgehen.
Von dieser Treibermodifikation nicht abgedeckt:
- Die ursprünglichen Core Solo/Core Duo (Yonah, nicht Core 2) sind Familie 6, Modell 14. Das ist gut, weil sie die C-Zustände C4E/C5 (Enhanced Deep Sleep) unterstützten, aber nicht die Zustände C1E/C2E und bräuchte eine eigene Idle-Definition.
Die einzigen Probleme, die mir einfallen, sind:
- Core 2 Solo SU3300/SU3500 (Penryn-L) sind Familie 6, Modell 23 und werden von diesem Treiber erkannt. Sie sind jedoch nicht Sockel LGA775, sodass sie den C1E Enhanced Halt C-State möglicherweise nicht unterstützen. Ebenso für den Core 2 Solo ULV U2100/U2200 (Merom-L). Allerdings ist die
130Der Treiber scheint den geeigneten C1/C1E basierend auf der Hardwareunterstützung der Unterzustände auszuwählen. - Core 2 Extreme QX9650 (Yorkfield) unterstützt Berichten zufolge C-State C2 oder C4 nicht. Ich habe dies durch den Kauf eines gebrauchten Optiplex 780 und QX9650 Extreme Prozessors bei eBay bestätigt. Der Prozessor unterstützt die C-Zustände C1 und C1E. Mit dieser Treibermodifikation befindet sich die CPU im Leerlauf im Zustand C1E statt C1, sodass vermutlich etwas Strom gespart wird. Ich habe erwartet, C-State C3 zu sehen, aber es ist nicht vorhanden, wenn ich diesen Treiber verwende, also muss ich das vielleicht weiter untersuchen.
Ich habe es geschafft, eine Folie aus einer Intel-Präsentation von 2009 über die Übergänge zwischen C-Zuständen (d. h. Deep Power Down) zu finden:
Zusammenfassend stellt sich heraus, dass es im 149 keinen wirklichen Grund für die fehlende Core 2-Unterstützung gab Treiber. Es ist jetzt klar, dass der ursprüngliche Stub-Code für „Core 2 Duo“ nur die C-Zustände C1 und C2 behandelte, was weit weniger effizient gewesen wäre als der 153 Funktion, die auch den C-Zustand C3 verarbeitet. Sobald ich wusste, wo ich suchen musste, war die Implementierung des Supports einfach. Die hilfreichen Kommentare und anderen Antworten wurden sehr geschätzt, und wenn Amazon zuhört, wissen Sie, wohin Sie den Scheck schicken müssen.
Dieses Update wurde an github übergeben. Ich werde bald einen Patch per E-Mail an LKML senden.
Aktualisieren :Ich habe es auch geschafft, einen Sockel T/LGA775 Allendale (Conroe) Core 2 Duo E2220, Familie 6, Modell 15, auszugraben, also habe ich auch dafür Unterstützung hinzugefügt. Dieses Modell hat keine Unterstützung für C-State C4, unterstützt aber C1/C1E und C2/C2E. Dies sollte auch für andere Conroe-basierte Chips (E4xxx/E6xxx) und möglicherweise alle Prozessoren von Kentsfield und Merom (nicht Merom-L) funktionieren.
Aktualisieren :Ich habe endlich einige MWAIT-Tuning-Ressourcen gefunden. Dieser Power-vs.-Performance-Bericht und dieser Blogbeitrag zu Deeper C-Zuständen und erhöhter Latenz enthalten beide einige nützliche Informationen zum Identifizieren von CPU-Leerlauflatenzen. Leider meldet dies nur die Ausgangslatenzen, die in den Kernel codiert wurden (aber interessanterweise nur die vom Prozessor unterstützten Hardwarezustände):
# 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
Aktualisierung: Ein Intel-Mitarbeiter hat kürzlich einen Artikel zu 168 veröffentlicht detaillierte MWAIT-Zustände.
Gibt es eine geeignetere Möglichkeit, einen Kernel für eine optimale CPU-Leerlaufunterstützung für diese Prozessorfamilie zu konfigurieren (abgesehen von der Deaktivierung der Unterstützung für intel_idle)
Sie haben ACPI aktiviert und überprüft, ob acpi_idle verwendet wird. Ich bezweifle aufrichtig, dass Sie eine hilfreiche Kernel-Konfigurationsoption verpasst haben. Sie können jederzeit 172 überprüfen für mögliche Vorschläge, aber das wussten Sie wahrscheinlich schon.
Dies ist keine Antwort, aber ich möchte sie formatieren :-(.
Wenn man sich den Kernel-Quellcode ansieht, enthält der aktuelle intel_idle-Treiber einen Test, um Intel-Familie 6 ausdrücklich aus dem Treiber auszuschließen.
Nein, tut es nicht :-).
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;
}
Die 184 -Anweisung schließt Familie 6 nicht aus. Stattdessen wird 193 -Anweisung liefert eine Meldung, wenn Debugging aktiviert ist, dass diese bestimmte moderne Intel-CPU nicht von 205 unterstützt wird . Tatsächlich ist meine aktuelle i5-5300U CPU Familie 6 und verwendet 216 .
Was Ihre CPU ausschließt, ist, dass es keine Übereinstimmung im 228 gibt Tabelle.
Mir ist dieser Commit aufgefallen, der die Tabelle implementiert hat. Der entfernte Code hatte einen 233 Aussage statt. Dadurch ist leicht zu erkennen, dass das früheste Modell „intel_idle“ implementiert/erfolgreich getestet wurde/was auch immer 0x1A =26 ist
Ich vermute, dass dies nur ein Fall von Gelegenheit und Kosten sein könnte. Wenn 243 wurde hinzugefügt, es scheint, dass Core 2 Duo-Unterstützung geplant war, aber nie vollständig implementiert wurde – vielleicht war es das nicht mehr wert, als die Intel-Ingenieure dazu kamen. Die Gleichung ist relativ komplex:255 muss ausreichende Vorteile gegenüber 267 bieten um es hier unterstützenswert zu machen, auf CPUs, die den „verbesserten“ Kernel in ausreichender Zahl sehen werden...
Wie die Antwort von sourcejedi sagt, schließt der Treiber nicht die gesamte Familie 6 aus. Der 276 Initialisierungsprüfungen für CPUs in einer Liste von CPU-Modellen, die im Grunde alle Mikroarchitekturen von Nehalem bis Kaby Lake abdecken. Yorkfield ist älter als das (und deutlich anders – Nehalem unterscheidet sich stark von den Architekturen, die davor kamen). Der Test der Familie 6 wirkt sich nur darauf aus, ob die Fehlermeldung gedruckt wird; seine Auswirkung ist lediglich, dass die Fehlermeldung nur auf Intel-CPUs angezeigt wird, nicht auf AMD-CPUs (Intel-Familie 6 umfasst alle Nicht-NetBurst-Intel-CPUs seit dem Pentium Pro).
Um Ihre Konfigurationsfrage zu beantworten, könnten Sie 281 vollständig deaktivieren , aber es ist auch in Ordnung, es drin zu lassen (solange Sie die Warnung nicht stören).