Cosa fa un processo CPU inattivo?

Osservando la fonte straceho trovato l'uso della bandiera del clone CLONE_IDLETASKche è descritta lì come:

#define CLONE_IDLETASK 0x00001000 /* kernel-only flag */

Dopo aver esaminato più a fondo, ho scoperto che, sebbene quel flag non sia coperto man clone, viene effettivamente utilizzato dal kernel durante il processo di avvio per creare processi inattivi (che dovrebbero avere tutti PID 0) per ogni CPU sulla macchina. cioè una macchina con 8 CPU avrà almeno 7 (vedi domanda sotto) tali processi "in esecuzione" (virgolette).

Ora, questo mi porta a un paio di domande su cosa faccia effettivamente quel processo "inattivo". La mia ipotesi è che esegue l'operazione NOP continuamente fino al termine del suo periodo di tempo e il kernel assegna un processo reale per eseguire o assegnare nuovamente il processo inattivo (se la CPU non viene utilizzata). Eppure, è un'ipotesi completa. Così:

1. Su una macchina con, diciamo, 8 CPU verranno creati 7 processi inattivi? (e una CPU sarà gestita dal kernel stesso mentre non si esegue alcun lavoro nello spazio utente?)

2. Il processo inattivo è davvero solo un flusso infinito di operazioni NOP? (o un ciclo che fa lo stesso).

3. L'utilizzo della CPU (diciamo uptime) è semplicemente calcolato da quanto tempo è rimasto il processo inattivo sulla CPU e da quanto tempo non è stato presente in un determinato periodo di tempo?

_{PS È probabile che buona parte di questa domanda sia dovuta al fatto che non capisco fino in fondo come funziona una CPU. cioè capisco l'assemblaggio, i tempi e gli interrupt ma non so come, ad esempio, una CPU possa usare più o meno energia a seconda di ciò che sta eseguendo. Le sarei grato se qualcuno potesse illuminarmi anche su questo.}

L'attività inattiva viene utilizzata per la contabilità di processo e anche per ridurre il consumo di energia. In Linux, viene creata un'attività inattiva per ogni processore e bloccata su quel processore; ogni volta che non c'è nessun altro processo da eseguire su quella CPU, l'attività inattiva è programmata. Il tempo impiegato nelle attività inattive viene visualizzato come tempo di inattività in strumenti come top. (Il tempo di attività viene calcolato in modo diverso.)

Unix sembra aver sempre avuto un ciclo di inattività di qualche tipo (ma non necessariamente un vero e proprio compito di inattività, vedi la risposta di Gilles ), e anche in V1 usava WAITun'istruzione che fermava il processore fino a quando si verificava un interruzione (stava per "wait for interrompere"). Alcuni altri sistemi operativi utilizzavano in particolare loop di occupato, DOS, OS / 2 e versioni precedenti di Windows. Da molto tempo ormai, le CPU hanno usato questo tipo di istruzioni di "attesa" per ridurre il consumo di energia e la produzione di calore. Puoi vedere varie implementazioni di task inattivi ad esempio nel arch/x86/kernel/process.ckernel di Linux: quello di base chiamaHLT, che arresta il processore fino a quando non si verifica un interruzione (e abilita la modalità di risparmio energetico C1), le altre implementazioni gestiscono vari bug o inefficienze ( ad es. utilizzando MWAITinvece che HLTsu alcune CPU).

Tutto ciò è completamente separato dagli stati inattivi nei processi, quando sono in attesa di un evento (I / O ecc.).

Nella progettazione del manuale di uno scheduler di processo, se lo scheduler non ha alcun processo da pianificare (cioè se tutti i processi sono bloccati, in attesa di input), allora lo scheduler attende un interruzione del processore. L'interruzione può indicare l'input da una periferica (azione dell'utente, pacchetto di rete, lettura completata da un disco, ecc.) O può essere un interruzione del timer che attiva un timer in un processo.

Lo scheduler di Linux non ha un codice speciale per un caso niente da fare. Invece, codifica il caso nulla da fare come un processo speciale, il processo inattivo. Il processo inattivo viene pianificato solo quando nessun altro processo è programmabile (ha effettivamente una priorità infinitamente bassa). Il processo inattivo è in realtà parte del kernel: è un thread del kernel, ovvero un thread che esegue il codice nel kernel, piuttosto che il codice in un processo. (Più precisamente, esiste un thread di questo tipo per ogni CPU.) Quando viene eseguito il processo inattivo, esegue l'operazione di attesa per l'interruzione.

La modalità di attesa dell'interruzione dipende dalle capacità del processore. Con il design del processore più semplice, questo è solo un loop occupato:

nothing:
    goto nothing

Il processore continua a eseguire un'istruzione di ramo per sempre, che non compie nulla. La maggior parte dei sistemi operativi moderni non lo fa a meno che non sia in esecuzione su un processore in cui non c'è niente di meglio e la maggior parte dei processori ha qualcosa di meglio. Invece di spendere energia senza fare altro che riscaldare la stanza, idealmente, il processore dovrebbe essere spento. Quindi il kernel esegue il codice che indica al processore di spegnersi, o almeno di spegnere la maggior parte del processore. Ci deve essere almeno una piccola parte che rimane accesa, il controller di interrupt. Quando una periferica attiva un interrupt, il controller di interruzione invierà un segnale di riattivazione al processore (parte del) principale.

In pratica, le moderne CPU come Intel / AMD e ARM hanno molte e complesse impostazioni di gestione dell'alimentazione. Il sistema operativo può stimare per quanto tempo il processore rimarrà in modalità inattiva e sceglierà diverse modalità a basso consumo a seconda di ciò. Le modalità offrono diversi compromessi tra il consumo di energia mentre è inattivo e il tempo necessario per entrare e uscire dalla modalità di inattività. Su alcuni processori il sistema operativo può anche abbassare la frequenza di clock del processore quando rileva che i processi non consumano molto tempo della CPU.

No, un'attività inattiva non spreca i cicli della CPU. Lo scheduler semplicemente non seleziona un processo inattivo per l'esecuzione. Un processo inattivo attende che si verifichi un evento in modo che possa continuare. Ad esempio, può essere in attesa di input in una read()chiamata di sistema.

A proposito, il kernel non è un processo separato. Il codice del kernel viene sempre eseguito nel contesto di un processo (beh, ad eccezione del caso speciale di un thread del kernel), quindi non è corretto dire "e una CPU verrà mantenuta dal kernel stesso mentre non viene eseguito alcun lavoro nello spazio utente".