Durante la ricerca degli stati di alimentazione della CPU del Core 2 ("Stati C "), sono effettivamente riuscito a implementare il supporto per la maggior parte dei processori legacy Intel Core/Core 2. L'implementazione completa (patch Linux) con tutte le informazioni di base è documentata qui.
Man mano che accumulavo più informazioni su questi processori, è diventato evidente che gli stati C supportati nei modelli Core 2 sono molto più complessi di quelli nei processori precedenti e successivi. Questi sono noti come Stati C migliorati (o "CxE "), che coinvolgono il pacchetto, i singoli core e altri componenti sul chipset (ad es. la memoria). All'epoca il intel_idle è stato rilasciato il driver, il codice non era particolarmente maturo ed erano stati rilasciati diversi processori Core 2 con supporto C-state in conflitto.
In questo articolo del 2006 sono state trovate alcune informazioni convincenti sul supporto Core 2 Solo/Duo C-state. Questo è in relazione al supporto su Windows, tuttavia indica il robusto supporto hardware C-state su questi processori. Le informazioni relative a Kentsfield sono in conflitto con il numero di modello effettivo, quindi credo che in realtà si riferiscano a uno Yorkfield di seguito:
...il processore quad-core Intel Core 2 Extreme (Kentsfield) supporta tutte e cinque le tecnologie di prestazioni e risparmio energetico:Enhanced Intel SpeedStep (EIST), Thermal Monitor 1 (TM1) e Thermal Monitor 2 (TM2), vecchia On-Demand Clock Modulation ( ODCM), nonché Stati C avanzati (CxE). Rispetto ai processori Intel Pentium 4 e Pentium D 600, 800 e 900, che sono caratterizzati solo da Enhanced Halt (C1) State, questa funzione è stata ampliata nei processori Intel Core 2 (così come nei processori Intel Core Solo/Duo) per tutti i possibili stati di inattività di un processore, inclusi Stop Grant (C2), Deep Sleep (C3) e DeeperSleep (C4).
Questo articolo del 2008 delinea il supporto per gli stati C per core su processori Intel multi-core, inclusi Core 2 Duo e Core 2 Quad (ulteriori utili letture di base sono state trovate in questo white paper di Dell):
Uno stato C di base è uno stato C hardware. Esistono diversi stati inattivi di base, ad es. CC1 e CC3. Come sappiamo, un moderno processore all'avanguardia ha più core, come i processori mobili Core DuoT5000/T7000 rilasciati di recente, noti come Penryn in alcuni circoli. Quello che pensavamo come una CPU / processore, in realtà ha più CPU generiche al suo fianco. L'Intel Core Duo ha 2 core nel chip del processore. L'Intel Core-2 Quad ha 4 di questi core per chip per processore. Ciascuno di questi core ha il proprio stato di inattività. Questo ha senso in quanto un core potrebbe essere inattivo mentre un altro è al lavoro su un thread. Quindi un core C-state è lo stato inattivo di uno di quei core.
Ho trovato una presentazione del 2010 di Intel che fornisce alcuni retroscena aggiuntivi sul intel_idle driver, ma sfortunatamente non spiega la mancanza di supporto per Core 2:
Questo driver SPERIMENTALE sostituisce acpi_idle su processori Intel Atom, processori Intel Core i3/i5/i7 e processori Intel Xeon associati. Non supporta il processore Intel Core2 o precedente.
La presentazione precedente indica che il intel_idle driver è un'implementazione del regolatore della CPU "menu", che ha un impatto sulla configurazione del kernel Linux (ad esempio, CONFIG_CPU_IDLE_GOV_LADDER contro CONFIG_CPU_IDLE_GOV_MENU ). Le differenze tra i governatori della scala e del menu sono brevemente descritte in questa risposta.
Dell ha un utile articolo che elenca la compatibilità C-state da C0 a C6:
Le modalità da C1 a C3 funzionano sostanzialmente tagliando i segnali di clock utilizzati all'interno della CPU, mentre le modalità da C4 a C6 funzionano riducendo la tensione della CPU. Le modalità "avanzate" possono eseguire entrambe le operazioni contemporaneamente.
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
Da questa tabella (che in seguito ho trovato errata in alcuni casi), sembra che ci fossero una varietà di differenze nel supporto dello stato C con i processori Core 2 (si noti che quasi tutti i processori Core 2 sono Socket LGA775, ad eccezione del Core 2 Solo SU3500, ovvero processori Socket BGA956 e Merom/Penryn. I processori "Intel Core" Solo/Duo sono uno dei processori Socket PBGA479 o PPGA478).
Un'ulteriore eccezione alla tabella è stata trovata in questo articolo:
Il Core 2 Duo E8500 di Intel supporta gli stati C2 e C4, mentre il Core 2Extreme QX9650 no.
È interessante notare che il QX9650 è un processore Yorkfield (famiglia Intel 6, modello 23, stepping 6). Per riferimento, il mio Q9550S è la famiglia Intel 6, modello 23 (0x17), stepping 10, che presumibilmente supporta C-state C4 (confermato attraverso la sperimentazione). Inoltre, il Core 2 Solo U3500 ha un CPUID identico (famiglia, modello, stepping) al Q9550S ma è disponibile in un socket non LGA775, il che confonde l'interpretazione della tabella precedente.
Chiaramente, il CPUID deve essere utilizzato almeno fino allo stepping per identificare il supporto C-state per questo modello di processore, e in alcuni casi potrebbe essere insufficiente (non determinato in questo momento).
La firma del metodo per l'assegnazione delle informazioni sulla CPU inattiva è:
#define ICPU(model, cpu) \
{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
Dove model è enumerato in asm/intel-family.h. Esaminando questo file di intestazione, vedo che alle CPU Intel sono assegnati identificatori a 8 bit che sembrano corrispondere ai numeri di modello della famiglia Intel 6:
#define INTEL_FAM6_CORE2_PENRYN 0x17
Da quanto sopra, abbiamo Intel Family 6, Model 23 (0x17) definito come INTEL_FAM6_CORE2_PENRYN . Questo dovrebbe essere sufficiente per definire gli stati di inattività per la maggior parte dei processori Model 23, ma potrebbe potenzialmente causare problemi con QX9650 come indicato sopra.
Quindi, come minimo, ogni gruppo di processori che ha un set di stato C distinto dovrebbe essere definito in questo elenco.
Zagacki e Ponnala, Intel Technology Journal 12 (3):219-227, 2008 indicano che i processori Yorkfield supportano effettivamente C2 e C4. Sembrano anche indicare che la specifica ACPI 3.0a supporta le transizioni solo tra gli stati C C0, C1, C2 e C3, che presumo possano anche limitare il Linux acpi_idle driver alle transizioni tra quel limitato insieme di stati C. Tuttavia, questo articolo indica che potrebbe non essere sempre così:
Tieni presente che è lo stato ACPI C, non quello del processore, quindi ACPIC3 potrebbe essere HW C6, ecc.
Da notare anche:
Oltre al processore stesso, poiché C4 è uno sforzo sincronizzato tra i principali componenti in silicio della piattaforma, il chipset Intel Q45 Express raggiunge un miglioramento della potenza del 28%.
Il chipset che sto usando è effettivamente un chipset Intel Q45 Express.
La documentazione Intel sugli stati MWAIT è concisa ma conferma il comportamento ACPI specifico del BIOS:
Gli stati C specifici del processore definiti nelle estensioni MWAIT possono essere mappati ai tipi di stato C definiti da ACPI (C0, C1, C2, C3). La relazione di mappatura dipende dalla definizione di uno stato C in base all'implementazione del processore ed è esposta a OSPM dal BIOS utilizzando la tabella _CST definita da ACPI.
La mia interpretazione della tabella sopra (combinata con una tabella di Wikipedia, asm/intel-family.h e gli articoli precedenti) è:
Modello 9 0x09 (Pentium M e Celeron M ):
- Bania:DO0, DO1, DO2, DO3, DO4
Modello 13 0x0D (Pentium M e Celeron M ):
- Dothan, Stealey:DO0, DO1, DO2, DO3, DO4
Modello 14 0x0E INTEL_FAM6_CORE_YONAH (Pentium M potenziato , Celeron M potenziato o Intel Core ):
- Yonah (Core Solo , Core Duo ):DO0, DO1, DO2, DO3, DO4, DO4E/DO5
Modello 15 0x0F INTEL_FAM6_CORE2_MEROM (alcuni 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 ):DO0, DO1, DO1E, DO2, DO2E
Modello 23 0x17 INTEL_FAM6_CORE2_PENRYN (Core 2 ):
- Merom-L/Penryn-L:?
- Penryn (Core 2 Duo 45-nm mobile ):DO0, DO1, DO1E, DO2, DO2E, DO3, DO4, DO4E/DO5, DO6
- Yorkfield (Core 2 Extreme QX9650 ):DO0, DO1, DO1E, DO2E?, DO3
- Wolfdale/Yorkfield (Core 2 Quad , C2Q Xeon , Core 2 Duo E5xxx/E7xxx/E8xxx , Pentium Dual Core E6xxx , Celeron Dual-Core ):DO0, DO1, DO1E, DO2, DO2E, DO3, DO4
Dalla quantità di diversità nel supporto dello stato C all'interno della sola linea di processori Core 2, sembra che la mancanza di un supporto coerente per gli stati C potrebbe essere stata la ragione per non tentare di supportarli completamente tramite intel_idle autista. Vorrei completare completamente l'elenco precedente per l'intera linea Core 2.
Questa non è davvero una risposta soddisfacente, perché mi chiedo quanta energia non necessaria venga utilizzata e quanto calore in eccesso sia stato (ed è tuttora) generato non utilizzando completamente i robusti stati C MWAIT a risparmio energetico su questi processori.
Chattopadhyay et al. 2018, Processori ad alte prestazioni ad alta efficienza energetica:Approcci recenti per la progettazione di computer ad alte prestazioni verdi è degno di nota per il comportamento specifico che sto cercando nel chipset Q45 Express:
Package C-state (PC0-PC10):quando i domini di calcolo, Core e Graphics (GPU) sono inattivi, il processore ha l'opportunità di ulteriori risparmi energetici a livello uncore e piattaforma, ad esempio, scaricando LLC e controllando l'alimentazione del controller di memoria e DRAM IO, e ad un certo stato, l'intero processore può essere spento mentre il suo stato viene mantenuto sul dominio di alimentazione sempre attivo.
Come test, ho inserito quanto segue in linux/drivers/idle/intel_idle.c riga 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 }
};
al intel_idle.c riga 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,
};
a intel_idle.c riga 1073:
ICPU(INTEL_FAM6_CORE2_MEROM, idle_cpu_conroe),
ICPU(INTEL_FAM6_CORE2_PENRYN, idle_cpu_core2),
Dopo una rapida compilazione e riavvio dei miei nodi PXE, dmesg ora 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 ora PowerTOP mostra:
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
Ho finalmente effettuato l'accesso agli stati C di Enhanced Core 2 e sembra che ci sia un calo misurabile del consumo energetico:il mio misuratore su 8 nodi sembra avere una media inferiore di almeno il 5% (con un nodo che esegue ancora il vecchio kernel) , ma proverò a scambiare nuovamente i kernel come test.
Una nota interessante riguardante il supporto C4E:il processore My Yorktown Q9550S sembra supportarlo (o qualche altro sottostato di C4), come evidenziato sopra! Questo mi confonde, perché la scheda tecnica Intel sul processore Core 2 Q9000 (sezione 6.2) menziona solo 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) e Deeper Sleep (C4 =0x30). Cos'è questo stato 0x31 aggiuntivo? Se abilito lo stato C2, viene utilizzato C4E invece di C4. Se disabilito lo stato C2 (forza lo stato C2E), viene utilizzato C4 invece di C4E. Sospetto che ciò possa avere qualcosa a che fare con i flag MWAIT, ma non ho ancora trovato la documentazione per questo comportamento.
Non sono sicuro di cosa pensare:lo stato C1E sembra essere usato al posto di C1, C2 è usato al posto di C2E e C4E è usato al posto di C4. Non sono sicuro se C1/C1E, C2/C2E e C4/C4E possano essere usati insieme a intel_idle o se sono ridondanti. Ho trovato una nota in questa presentazione del 2010 di Intel Labs Pittsburgh che indica che le transizioni sono C0 - C1 - C0 - C1E - C0 e ulteriori affermazioni:
C1E viene utilizzato solo quando tutti i core sono in C1E
Credo che debba essere interpretato come lo stato C1E viene inserito su altri componenti (ad es. Memoria) solo quando tutti i core sono nello stato C1E. Presumo anche che questo si applichi in modo equivalente agli stati C2/C2E e C4/C4E (sebbene C4E sia indicato come "C4E/C5", quindi non sono sicuro se C4E sia un sub-stato di C4 o se C5 sia un sub- stato di C4E. Il test sembra indicare che C4/C4E è corretto). Posso forzare l'utilizzo di C2E commentando lo stato C2, tuttavia, ciò fa sì che venga utilizzato lo stato C4 invece di C4E (qui potrebbe essere necessario più lavoro). Si spera che non ci siano processori modello 15 o modello 23 privi dello stato C2E, poiché tali processori sarebbero limitati a C1/C1E con il codice precedente.
Inoltre, i flag, i valori di latenza e residenza potrebbero probabilmente essere messi a punto, ma solo fare ipotesi plausibili basate sui valori di inattività di Nehalem sembra funzionare bene. Saranno necessarie ulteriori letture per apportare eventuali miglioramenti.
L'ho testato su 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) e Core 2 Extreme QX9650, e ho non hanno riscontrato problemi oltre alla suddetta preferenza per lo stato C2/C2E e C4/C4E.
Non coperto da questa modifica del driver:
- L'originale Core Solo/Core Duo (Yonah, non Core 2) è della famiglia 6, modello 14. Questo è positivo perché supportavano gli stati C C4E/C5 (Enhanced Deep Sleep) ma non gli stati C1E/C2E e avrebbe bisogno della propria definizione inattiva.
Gli unici problemi che mi vengono in mente sono:
- I Core 2 Solo SU3300/SU3500 (Penryn-L) appartengono alla famiglia 6, modello 23 e verranno rilevati da questo driver. Tuttavia, non sono Socket LGA775, quindi potrebbero non supportare lo stato C C1E Enhanced Halt. Allo stesso modo per il Core 2 Solo ULV U2100/U2200 (Merom-L). Tuttavia, il
intel_idlesembra che il driver scelga il C1/C1E appropriato in base al supporto hardware dei sottostati. - Secondo quanto riferito, Core 2 Extreme QX9650 (Yorkfield) non supporta C-state C2 o C4. L'ho confermato acquistando un processore Optiplex 780 e QX9650 Extreme usato su eBay. Il processore supporta gli stati C C1 e C1E. Con questa modifica del driver, la CPU è idle nello stato C1E invece che C1, quindi c'è presumibilmente un po' di risparmio energetico. Mi aspettavo di vedere C-state C3, ma non è presente quando si utilizza questo driver, quindi potrei aver bisogno di approfondire ulteriormente.
Sono riuscito a trovare una diapositiva di una presentazione Intel del 2009 sulle transizioni tra gli stati C (ovvero Deep Power Down):
In conclusione, si scopre che non c'era una vera ragione per la mancanza del supporto Core 2 nel intel_idle autista. È chiaro ora che il codice stub originale per "Core 2 Duo" gestiva solo gli stati C C1 e C2, che sarebbero stati molto meno efficienti del acpi_idle funzione che gestisce anche lo stato C C3. Una volta che ho saputo dove cercare, implementare il supporto è stato facile. I commenti utili e le altre risposte sono state molto apprezzate e, se Amazon ti sta ascoltando, sai dove inviare l'assegno.
Questo aggiornamento è stato eseguito su github. Presto invierò via e-mail una patch a LKML.
Aggiorna :Sono anche riuscito a scovare un Socket T/LGA775 Allendale (Conroe) Core 2 Duo E2220, che è la famiglia 6, modello 15, quindi ho aggiunto il supporto anche per quello. Questo modello non supporta C-state C4, ma supporta C1/C1E e C2/C2E. Questo dovrebbe funzionare anche per altri chip basati su Conroe (E4xxx/E6xxx) e forse per tutti i processori Kentsfield e Merom (non Merom-L).
Aggiorna :ho finalmente trovato alcune risorse per l'ottimizzazione di MWAIT. Questo articolo su Power vs. Performance e questo Deeper C dichiara e post sul blog sulla latenza aumentata contengono entrambi alcune informazioni utili sull'identificazione delle latenze inattive della CPU. Sfortunatamente, questo riporta solo quelle latenze di uscita che sono state codificate nel kernel (ma, curiosamente, solo quegli stati hardware supportati dal processore):
# 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
Aggiornamento: Un dipendente Intel ha recentemente pubblicato un articolo su intel_idle dettaglio degli stati MWAIT.
Esiste un modo più appropriato per configurare un kernel per un supporto ottimale della CPU inattiva per questa famiglia di processori (oltre a disabilitare il supporto per intel_idle)
Hai ACPI abilitato e hai verificato che acpi_idle è in uso. Dubito sinceramente che tu abbia perso qualche utile opzione di configurazione del kernel. Puoi sempre selezionare powertop per eventuali suggerimenti, ma probabilmente lo sapevi già.
Questa non è una risposta, ma voglio formattarla :-(.
Osservando il codice sorgente del kernel, l'attuale driver intel_idle contiene un test per escludere specificatamente la famiglia Intel 6 dal driver.
No, non è così :-).
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;
}
Il if l'istruzione non esclude la Famiglia 6. Al contrario, l'istruzione if fornisce un messaggio quando il debug è abilitato, che questa specifica CPU Intel moderna non è supportata da intel_idle . In effetti, la mia attuale CPU i5-5300U è della famiglia 6 e utilizza intel_idle .
Ciò che esclude la tua CPU è che non c'è corrispondenza nel intel_idle_ids tabella.
Ho notato questo commit che ha implementato la tabella. Il codice che rimuove aveva un switch dichiarazione invece. Questo rende facile vedere che il primo modello intel_idle è stato implementato/testato con successo/qualunque sia 0x1A =26. https://github.com/torvalds/linux/commit/b66b8b9a4a79087dde1b358a016e5c8739ccf186
Sospetto che questo potrebbe essere solo un caso di opportunità e costi. Quando intel_idle è stato aggiunto, sembra che il supporto Core 2 Duo fosse pianificato, ma non è mai stato completamente implementato - forse quando gli ingegneri Intel ci sono riusciti, non ne valeva più la pena. L'equazione è relativamente complessa:intel_idle deve fornire vantaggi sufficienti rispetto a acpi_idle per renderlo degno di supporto qui, su CPU che vedranno il kernel "migliorato" in numero sufficiente...
Come dice la risposta di sourcejedi, il conducente non esclude tutta la famiglia 6. Il intel_idle l'inizializzazione controlla le CPU in un elenco di modelli di CPU, coprendo praticamente tutte le microarchitetture da Nehalem a Kaby Lake. Yorkfield è più vecchio di quello (e significativamente diverso:Nehalem è molto diverso dalle architetture che l'hanno preceduto). Il test della famiglia 6 influisce solo sulla stampa del messaggio di errore; il suo effetto è solo che il messaggio di errore verrà visualizzato solo sulle CPU Intel, non sulle CPU AMD (la famiglia Intel 6 include tutte le CPU Intel non NetBurst a partire dal Pentium Pro).
Per rispondere alla tua domanda sulla configurazione, puoi disabilitare completamente intel_idle , ma anche lasciarlo inserito va bene (purché non ti dispiaccia l'avvertimento).