Skip to content

Perché alcuni modelli di CPU della famiglia Intel 6 (Core 2, Pentium M) non sono supportati da intel_idle?

Dopo aver consultato specialisti in materia, programmatori di varie aree e docenti, abbiamo trovato la risposta al problema e la condividiamo in questo post.

Soluzione:

Durante la ricerca di Core 2 Stati di alimentazione della CPU ("Stati C"), sono riuscito a implementare il supporto per la maggior parte dei processori Intel Core/Core 2 tradizionali. L'implementazione completa (patch per Linux) con tutte le informazioni di base è documentata qui.

Man mano che accumulavo informazioni su questi processori, iniziava a diventare evidente che gli stati C supportati nei modelli Core 2 sono molto più complessi di quelli dei processori precedenti e successivi. Questi sono noti come Stati C migliorati (o "CxE"), che riguardano il pacchetto, i singoli core e altri componenti del chipset (ad esempio, la memoria). Nel momento in cui il intel_idle il codice non era ancora particolarmente maturo e sono stati rilasciati diversi processori Core 2 con supporto allo stato C in conflitto tra loro.

Alcune informazioni interessanti sul supporto allo stato C dei Core 2 Solo/Duo sono state trovate in questo articolo del 2006. Questo si riferisce al supporto su Windows, ma indica il solido supporto hardware C-state su questi processori. Le informazioni relative a Kentsfield sono in conflitto con il numero di modello effettivo, quindi credo che si riferiscano in realtà a uno Yorkfield:

...il processore quad-core Intel Core 2 Extreme (Kentsfield) supporta
tutte e cinque le tecnologie di risparmio energetico e di prestazioni - Enhanced Intel
SpeedStep (EIST), Thermal Monitor 1 (TM1) e Thermal Monitor 2 (TM2),
la vecchia On-Demand Clock Modulation (ODCM) e gli Stati C migliorati (CxE).
(CxE). Rispetto ai processori Intel Pentium 4 e Pentium D 600, 800 e 900
che sono caratterizzati solo dallo stato Enhanced Halt (C1),
questa funzione è stata ampliata nei processori Intel Core 2 (e nei processori Intel Core Solo/Duo).
Intel Core Solo/Duo) per tutti i possibili stati di inattività di un processore, compreso lo Stop Grant (C2).
processore, tra cui Stop Grant (C2), Deep Sleep (C3) e Deeper Sleep (C4).
sonno più profondo (C4).

Questo articolo del 2008 illustra il supporto per gli stati C per core sui processori Intel multicore, compresi i Core 2 Duo e i Core 2 Quad (un'ulteriore utile lettura di base si trova in questo white paper di Dell):

Uno stato C per core è uno stato C hardware. Esistono diversi stati di inattività del
core, ad esempio CC1 e CC3. Come sappiamo, un moderno processore allo stato dell'arte
moderno ha più core, come ad esempio i recenti processori mobili Core Duo
T5000/T7000, noti come Penryn in alcuni ambienti. Quello che
che eravamo abituati a considerare come una CPU/un processore, in realtà ha più
CPU di uso generale. L'Intel Core Duo ha 2 core nel chip del processore.
nel chip del processore. L'Intel Core-2 Quad ha 4 core per chip.
chip del processore. Ciascuno di questi core ha un proprio stato di inattività. Questo ha senso
senso, poiché un core potrebbe essere inattivo mentre un altro è impegnato in un thread.
thread. Quindi uno stato C del core è lo stato di inattività di uno di questi core.

Ho trovato una presentazione di Intel del 2010 che fornisce alcune informazioni aggiuntive sullo stato di inattività dei core. intel_idle ma sfortunatamente non spiega la mancanza di supporto per Core 2:

Questo driver SPERIMENTALE sostituisce acpi_idle sui processori Intel Atom
Atom, processori Intel Core i3/i5/i7 e processori Intel Xeon associati.
associati. Non supporta i processori Intel Core2 o precedenti.

La presentazione di cui sopra indica che l'opzione intel_idle è un'implementazione del governatore della CPU "menu", che ha un impatto sulla configurazione del kernel Linux (ad es, CONFIG_CPU_IDLE_GOV_LADDER contro CONFIG_CPU_IDLE_GOV_MENU.CONFIG_CPU_IDLE_GOV_MENU). Le differenze tra i regolatori ladder e quelli a menu sono descritte sinteticamente in questa risposta.

Dell ha un utile articolo che elenca la compatibilità degli stati C da C0 a C6:

Le modalità da C1 a C3 funzionano sostanzialmente tagliando i segnali di clock utilizzati all'interno della CPU.
CPU, mentre le modalità da C4 a C6 funzionano riducendo la tensione della CPU. Le modalità "potenziate"
possono fare entrambe le cose allo stesso tempo.

Mode   Name                   CPUs
C0     Operating State        All CPUs
C1     Halt                   486DX4 and above
C1E    Enhanced Halt          All socket LGA775 CPUs
C1E    —                      Turion 64, 65-nm Athlon X2 and Phenom CPUs
C2     Stop Grant             486DX4 and above
C2     Stop Clock             Only 486DX4, Pentium, Pentium MMX, K5, K6, K6-2, K6-III
C2E    Extended Stop Grant    Core 2 Duo and above (Intel only)
C3     Sleep                  Pentium II, Athlon and above, but not on Core 2 Duo E4000 and E6000
C3     Deep Sleep             Pentium II and above, but not on Core 2 Duo E4000 and E6000; Turion 64
C3     AltVID                 AMD Turion 64
C4     Deeper Sleep           Pentium M and above, but not on Core 2 Duo E4000 and E6000 series; AMD Turion 64
C4E/C5 Enhanced Deeper Sleep  Core Solo, Core Duo and 45-nm mobile Core 2 Duo only
C6     Deep Power Down        45-nm mobile Core 2 Duo only

Da questa tabella (che in seguito ho scoperto essere errata in alcuni casi), risulta che ci sono diverse 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, che è Socket BGA956 e dei processori Merom/Penryn. I processori "Intel Core" Solo/Duo sono uno dei Socket PBGA479 o PPGA478).

In questo articolo è stata trovata un'ulteriore eccezione alla tabella:

Il Core 2 Duo E8500 di Intel supporta gli stati C C2 e C4, mentre il Core 2
Extreme QX9650 non lo supporta.

È interessante notare che il QX9650 è un processore Yorkfield (famiglia Intel 6, modello 23, passo 6). Per riferimento, il mio Q9550S è della famiglia Intel 6, modello 23 (0x17), stepping 10, che presumibilmente supporta lo stato C4 (confermato dalla sperimentazione). Inoltre, il Core 2 Solo U3500 ha un CPUID (famiglia, modello, stepping) identico a quello del 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 dello stato C per questo modello di processore, e in alcuni casi potrebbe essere insufficiente (al momento non è determinato).

La firma del metodo per assegnare le 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, si nota che alle CPU Intel vengono 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 la famiglia Intel 6, modello 23 (0x17) definita come INTEL_FAM6_CORE2_PENRYN. Questo dovrebbe essere sufficiente per definire gli stati di idle per la maggior parte dei processori modello 23, ma potrebbe potenzialmente causare problemi con il QX9650, come notato in precedenza.

Quindi, come minimo, ogni gruppo di processori che ha un set di stati C distinto deve essere definito in questo elenco.

Zagacki e Ponnala, Giornale della tecnologia Intel12(3):219-227, 2008 indicano che i processori Yorkfield supportano effettivamente C2 e C4. Sembrano anche indicare che le specifiche ACPI 3.0a supportano solo le transizioni tra gli stati C0, C1, C2 e C3, il che presumo possa anche limitare le possibilità di utilizzo di Linux. acpi_idle Linux alle transizioni tra questo insieme limitato di stati C. Tuttavia, questo articolo indica che potrebbe non essere sempre così:

Si tenga presente che si tratta dello stato C di ACPI, non di quello del processore, quindi ACPI
C3 potrebbe essere HW C6, ecc.

Da notare anche:

Al di là del processore stesso, dal momento che C4 è uno sforzo sincronizzato tra i principali componenti di silicio della piattaforma, l'Intel C4 è un'applicazione di
principali componenti di silicio della piattaforma, il chipset Intel Q45 Express
Q45 Express Chipset raggiunge un miglioramento della potenza del 28%.

Il chipset che sto utilizzando è effettivamente un chipset Intel Q45 Express.

La documentazione di Intel sugli stati MWAIT è breve, ma conferma il comportamento ACPI specifico del BIOS:

Gli stati C specifici del processore definiti nelle estensioni MWAIT possono essere mappati a
tipi di stato C definiti da ACPI (C0, C1, C2, C3). La relazione di mappatura
dipende dalla definizione di uno stato C da parte dell'implementazione del processore e
è esposta a OSPM dal BIOS utilizzando la tabella _CST definita da ACPI.

La mia interpretazione della tabella di cui sopra (combinata con una tabella tratta da Wikipedia, asm/intel-family.h e dagli articoli precedenti) è la seguente:

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

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

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

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

Modello 14 0x0E INTEL_FAM6_CORE_YONAH (Pentium M migliorato, Celeron M migliorato o Intel Core):

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

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): C0, C1, C1E, C2, C2E

Modello 23 0x17 INTEL_FAM6_CORE2_PENRYN (Core 2):

  • Merom-L/Penryn-L: ?
  • Penryn (Core 2 Duo 45-nm 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 Dual-Core E6xxx, Celeron Dual-Core): C0, C1, C1E, C2, C2E, C3, C4

Dalla quantità di diversità nel supporto degli stati C all'interno della sola linea di processori Core 2, sembra che la mancanza di un supporto coerente per gli stati C possa essere stata la ragione per cui non si è cercato di supportarli completamente tramite il metodo intel_idle driver. Vorrei completare l'elenco di cui sopra per l'intera linea Core 2.

Questa non è una risposta soddisfacente, perché mi fa pensare a quanta energia inutile è stata consumata e a quanto calore in eccesso è stato (ed è tuttora) generato dal mancato utilizzo dei robusti stati C MWAIT per il risparmio energetico su questi processori.

Chattopadhyay et al. 2018, Energy Efficient High Performance Processors: Recent Approaches for Designing Green High Performance Computing è degno di nota per il comportamento specifico che sto cercando nel chipset Q45 Express:

Stato del pacchetto C (PC0-PC10) - Quando i domini di calcolo, Core e Grafica (GPU) sono inattivi.
grafica (GPU) sono inattivi, il processore ha l'opportunità di risparmiare energia
ulteriori risparmi energetici a livello di uncore e di piattaforma, ad esempio,
lavaggio dell'LLC e power-gating del controller di memoria e dell'IO della DRAM,
e in alcuni stati, l'intero processore può essere spento mentre il suo
stato viene conservato nel dominio di alimentazione sempre attivo.

Come test, ho inserito quanto segue alla riga 127 di 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 }
};

a 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 il 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 avuto accesso agli stati C dell'Enhanced Core 2 e sembra che ci sia un calo misurabile nel consumo di energia - il mio misuratore su 8 nodi sembra avere una media di almeno il 5% in meno (con un nodo che esegue ancora il vecchio kernel), ma proverò a scambiare di nuovo i kernel come test.

Una nota interessante riguardo al supporto di C4E: il mio processore Yorktown Q9550S sembra supportarlo (o qualche altro sotto-stato di C4), come evidenziato sopra! Questo mi confonde, perché la scheda tecnica Intel sul processore Core 2 Q9000 (sezione 6.2) menziona solo gli stati C Normal (C0), HALT (C1 = 0x00), HALT esteso (C1E = 0x01), Stop Grant (C2 = 0x10), Stop Grant esteso (C2E = 0x11), Sleep/Deep Sleep (C3 = 0x20) e Deeper Sleep (C4 = 0x30). Che cos'è questo stato aggiuntivo 0x31? Se abilito lo stato C2, viene utilizzato C4E invece di C4. Se disabilito lo stato C2 (forzando lo stato C2E), viene utilizzato C4 invece di C4E. Sospetto che questo possa avere a che fare con i flag MWAIT, ma non ho ancora trovato documentazione su questo comportamento.

Non so cosa pensare di questo: 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 che 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 degli Intel Labs di Pittsburgh che indica che le transizioni sono C0 - C1 - C0 - C1E - C0, e afferma inoltre:

C1E è utilizzato solo quando tutti i core sono in C1E

Credo che questo vada interpretato nel senso che lo stato C1E viene inserito in altri componenti (ad esempio la memoria) solo quando tutti i core sono nello stato C1E. Ritengo che ciò si applichi anche agli stati C2/C2E e C4/C4E (sebbene C4E sia indicato come "C4E/C5", quindi non so se C4E sia un sotto-stato di C4 o se C5 sia un sotto-stato di C4E). I test sembrano indicare che C4/C4E è corretto). Posso forzare l'uso di C2E commentando lo stato C2, ma questo fa sì che venga usato lo stato C4 invece di C4E (potrebbe essere necessario ulteriore lavoro). Si spera che non ci siano processori modello 15 o modello 23 che non abbiano lo stato C2E, perché questi processori sarebbero limitati a C1/C1E con il codice precedente.

Inoltre, i valori dei flag, della latenza e della residenza potrebbero probabilmente essere messi a punto, ma basta fare delle ipotesi basate sui valori di idle di Nehalem per capire che funziona bene. Saranno necessarie ulteriori letture per apportare qualsiasi miglioramento.

Ho testato questo su 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) e un Core 2 Extreme QX9650, e non ho riscontrato alcun problema oltre alla già citata preferenza per gli stati C2/C2E e C4/C4E.

Non coperto da questa modifica del driver:

  • I Core Solo/Core Duo originali (Yonah, non Core 2) appartengono alla famiglia 6, modello 14. Questo è un bene perché supportavano gli stati C4E/C5 (Enhanced Deep Sleep) ma non gli stati C1E/C2E e avrebbero avuto bisogno di una propria definizione di idle.

Gli unici problemi che mi vengono in mente sono:

  • I Core 2 Solo SU3300/SU3500 (Penryn-L) sono della famiglia 6, modello 23 e vengono rilevati da questo driver. Tuttavia, non sono Socket LGA775 e quindi potrebbero non supportare lo stato C C1E Enhanced Halt. Lo stesso vale per i Core 2 Solo ULV U2100/U2200 (Merom-L). Tuttavia, il intel_idle sembra scegliere il C1/C1E appropriato in base al supporto hardware dei sotto-stati.
  • Il Core 2 Extreme QX9650 (Yorkfield) non supporta lo stato C C2 o C4. L'ho confermato acquistando su eBay un Optiplex 780 usato e un processore QX9650 Extreme. Il processore supporta gli stati C C1 e C1E. Con questa modifica del driver, la CPU si trova nello stato C1E anziché C1, quindi presumibilmente si ottiene un risparmio energetico. Mi aspettavo di vedere lo stato C3, ma non è presente quando si utilizza questo driver, quindi potrei dover approfondire l'argomento.

Sono riuscito a trovare una diapositiva di una presentazione Intel del 2009 sulle transizioni tra gli stati C (cioè Deep Power Down):

Deep Power Down Technology Entry/Exit

In conclusione, è emerso che non c'era una vera ragione per la mancanza di supporto Core 2 nel driver intel_idle nel driver. Ora è chiaro che il codice stub originale per "Core 2 Duo" gestiva solo gli stati C C1 e C2, il che sarebbe stato molto meno efficiente del driver intel_idle . acpi_idle che gestisce anche lo stato C3. Una volta capito dove cercare, implementare il supporto è stato facile. I commenti utili e le altre risposte sono stati molto apprezzati e se Amazon è in ascolto, sapete dove inviare l'assegno.

Questo aggiornamento è stato inviato a github. Invierò presto una patch al LKML.

Aggiornamento: Sono anche riuscito a trovare un Socket T/LGA775 Allendale (Conroe) Core 2 Duo E2220, che è la famiglia 6, modello 15, quindi ho aggiunto il supporto anche per questo. Questo modello non supporta lo stato C4, ma supporta C1/C1E e C2/C2E. Questo dovrebbe funzionare anche per altri chip basati su Conroe (E4xxx/E6xxx) e probabilmente per tutti i processori Kentsfield e Merom (non Merom-L).

Aggiornamento: Ho finalmente trovato alcune risorse per la messa a punto del MWAIT. Questo documento Power vs. Performance e questo post del blog Deeper C states and increased latency contengono entrambi alcune informazioni utili per identificare le latenze di inattività della CPU. Sfortunatamente, questo riporta solo le latenze di uscita che sono state codificate nel kernel (ma, cosa interessante, solo gli 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 di Intel ha recentemente pubblicato un articolo su intel_idleche descrive in dettaglio gli stati MWAIT.

C'è un modo più appropriato per configurare un kernel per il supporto ottimale dell'idle della CPU per questa famiglia di processori (a parte disabilitare il supporto per intel_idle)?

Avete abilitato ACPI e avete controllato che acpi_idle sia in uso. Sinceramente dubito che vi sia sfuggita qualche opzione utile per la configurazione del kernel. Si può sempre controllare powertop per eventuali suggerimenti, ma probabilmente lo sapevate già.


Questa non è una risposta, ma voglio formattarla :-(.

Guardando il codice sorgente del kernel, l'attuale driver intel_idle contiene un test per escludere specificamente la famiglia Intel 6 dal driver.

No, non c'è :-).

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 %dn",
            boot_cpu_data.x86, boot_cpu_data.x86_model);
    return -ENODEV;
}

Il if non esclude la Famiglia 6. Invece, 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 CPU i5-5300U attuale è della famiglia 6 e utilizza intel_idle.

Ciò che esclude la vostra CPU è che non c'è alcuna corrispondenza nel parametro intel_idle_ids nella tabella intel_idle_ids.

Ho notato questo commit che implementa la tabella. Il codice che rimuove aveva un switch al suo posto. In questo modo è facile vedere che il primo modello di intel_idle implementato/testato con successo/quello che è è 0x1A = 26. https://github.com/torvalds/linux/commit/b66b8b9a4a79087dde1b358a016e5c8739ccf186

Sospetto che si tratti di un caso di opportunità e di costi. Quando intel_idle è stato aggiunto, sembra che il supporto per Core 2 Duo sia stato pianificato, ma non è mai stato implementato completamente - forse quando gli ingegneri di Intel ci sono arrivati, non ne valeva più la pena. L'equazione è relativamente complessa: intel_idle deve fornire vantaggi sufficienti rispetto a acpi_idle perché valga la pena supportarlo qui, sulle CPU che vedranno il kernel "migliorato" in numero sufficiente...

Come dice la risposta di sourcejedi, il driver non esclude tutta la famiglia 6. L'opzione intel_idleverifica la presenza di CPU in un elenco di modelli di CPU che copre sostanzialmente tutte le microarchitetture da Nehalem a Kaby Lake. Yorkfield è più vecchio (e significativamente diverso - Nehalem è molto diverso dalle architetture che lo hanno preceduto). Il test della famiglia 6 influisce solo sulla stampa o meno del messaggio di erroreed; il suo effetto è solo che il messaggio di errore verrà visualizzato solo sulle CPU Intel, non su quelle AMD (la famiglia 6 di Intel include tutte le CPU Intel non NetBurst a partire dal Pentium Pro).

Per rispondere alla domanda sulla configurazione, si potrebbe disabilitare completamente intel_idlema anche lasciarlo inserito va bene (a patto che non vi dia fastidio l'avviso).

Ricorda che puoi condividere questo post se ti è stato di aiuto.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.