SISTEMI OPERATIVI SCHEDULING CPU

Continuiamo il nostro viaggio nei moderni sistemi operativi analizzando lo scheduling della CPU, trattato nel capitolo 5 del libro “Sistemi operativi. Concetti ed esempi.” di  Abraham SilberschatzPeter Baer GalvinGreg GagneR. Melen, decima edizione (qui per il precedente capitolo sui processi).

Per una maggiore comprensione del testo, occorre una discreta conoscenza del linguaggio di programmazione C (qui i migliori da noi consigliati) e Java (qui i migliori da noi consigliati)

5.1 Concetti fondamentali

L’obiettivo della multiprogrammazione è tenere più processi in memoria per massimizzare l’uso della CPU. Un processo, quindi, continuerà ad essere eseguito fintanto che non debba attendere un evento (richiesta di I/O). Durante l’attesa, il processo passa in uno stato di attesa e viene inserito in una delle code di processi in attesa, quindi si assegna alla CPU un’altro processo preso dalla coda dei processi pronti. Questo è detto scheduling ed è una funzione fondamentale dei sistemi operativi.

Schema riassuntivo degli stati di un processo in un moderno sistema operativo

5.1.1 Ciclicità delle fasi d’elaborazione e di I/O

L’esecuzione del processo consiste in un ciclo di elaborazione svolto dalla CPU e di un’attesa del completamento di operazioni I/O (ricorda la tipologia processi CPU bound e I/O bound del capitolo 3). I processi si alternano tra questi due stati, detti rispettivamente esecuzione e attesa.

Una sequenza tipica può essere così descritta:

  1. sequenza di operazioni svolte dalla CPU cpu burst
  2. sequenza di operazioni I/O I/O burst
  3. sequenza di operazioni svolte dalla CPU cpu burst
  4. sequenza di operazioni I/O I/O burst
  5. e così via fin quando non si incontra l’ultima sequenza di operazioni che richiede di terminare l’esecuzione.

Attraverso delle misurazioni empiriche si è constatato che quasi tutti i processi presentano una curva di frequenza di tipo esponenziale, con molte sequenze brevi di operazioni della CPU e poche sequenze di operazioni CPU molto lunghe.

  • Un programma con prevalenza di I/O bound presenta molte sequenze di operazioni di CPU a breve durata 
  • Un programma con prevalenza di CPU bound presenta sequenze di operazioni della CPU molto lunghe

Tenendo conto di questa distinzione, si può scegliere un algoritmo di scheduling appropriato della CPU.

5.1.2 Scheduler CPU

Ogni volta che la CPU diventa inattiva, è compito dello scheduler CPU (detto anche scheduler a breve termine) selezionare un altro processo dalla coda dei processi pronti (ready queue) per l’esecuzione successiva.

La struttura di archiviazione per la coda dei processi pronti e l’algoritmo utilizzato per selezionare il processo successivo non sono necessariamente una coda FIFO (First In First Out), ma possono variare.

5.1.3. Pianificazione preventiva

Le decisioni sulla pianificazione della CPU si svolgono in una di queste quattro condizioni:

  1. Quando un processo passa dallo stato di esecuzione allo stato di attesa, ad esempio per una richiesta I/O o a seguito della chiamata di sistema wait() nell’attesa che un processo figlio termini.
  2. Quando un processo passa dallo stato di esecuzione allo stato pronto, ad esempio in risposta a un segnale di interruzione.
  3. Quando un processo passa dallo stato di attesa allo stato pronto, ad esempio al completamento dell’I/O o un ritorno da wait().
  4. Quando termina un processo.

Se per le condizioni 1 e 4 è necessario selezionare un nuovo processo, per le condizioni 2 e 3 si può scegliere se:

  • continuare a eseguire il processo corrente
  • selezionarne un diverso processo

Se lo scheduling avviene solo alle condizioni 1 e 4, si dice che il sistema è senza prelazione  (nonpreempitive) o cooperativo (cooperative) . In queste condizioni, una volta che un processo è in stato di esecuzione, permane in questo stato fino a quando non si pone in stato di attesa volontariamente o in stato di terminazione.

Se lo scheduling tiene conto anche alle condizioni 2 e 3, si dice che il sistema sia con prelazione (preempitive). Tutti i sistemi operativi usano algoritmi di scheduling con prelazione preempitive.

Windows ha utilizzato lo scheduling senza prelazione fino a Windows 3.x e usa lo scheduling con prelazione da Win95. I Mac usano lo scheduling con prelazione da OSX. Lo scheduling con prelazione è possibile solo su hardware che supporta un interrupt del timer.

Lo scheduling con prelazione può causare problemi quando due processi condividono dati, poiché un processo può essere interrotto durante l’aggiornamento delle strutture di dati condivise (capitolo 6 race condition).

Lo scheduling con prelazione può anche essere un problema se il kernel è impegnato con una chiamata di sistema (ad es. aggiornamento critico delle strutture dati del kernel).

Un kernel senza prelazione attende che un processo termini o si blocchi prima di eseguire un cambio di contesto context switch (capitolo 3). Questa soluzione è vantaggiosa perché rende semplice la struttura del kernel stesso, ma è problematica per i sistemi in tempo reale, poiché i processi devono concludersi in un determinato tempo.

Un kernel con prelazione deve avere meccanismi appositi (lock mutex) per prevenire le race condition. Alcune sezioni critiche del codice si proteggono dai problemi del modello con prelazione disabilitando l’ascolto dei segnali di interruzione prima di accedere alla sezione critica, quindi riattivando l’ascolto all’uscita dalla sezione. Inutile dire che questo dovrebbe essere fatto solo in rare situazioni e solo su pezzi di codice molto brevi che finiranno rapidamente (di solito solo alcune istruzioni della macchina).

5.1.4 Dispatcher

Il dispatcher è il modulo che dà il controllo della CPU al processo selezionato dallo scheduler a breve termine. Questa funzione prevede i seguenti passi:

  • Cambio di contesto da un processo ad un altro.
  • Passaggio alla modalità utente.
  • Saltare nella giusta istruzione del programma appena caricato (tramite il valore del program counter) per riavviarne l’esecuzione.

Il dispatcher deve essere il più veloce possibile, poiché viene eseguito su ogni cambio di contesto. Il tempo impiegato dal dispatcher per fermare un processo e avviare l’esecuzione del successivo è noto come latenza di spedizione.

Su Linux è possibile conoscere il numero di cambi di contesto in un dato periodo temporale mediante comando

vmstat 1 3 

con (1 3) intervallo di tre secondi dove avvengono i cambi di contesto. Si può anche individuare la directory /proc/

per verificare i processi attivi elencati mediante il relativo PID process id. Per capire a quale processo si riferisce un PID, dai il comando:

 ps -el 

Tramite vmstat possiamo scoprire quali sono i cambi di contesto volontari (quando un processo cede il controllo della CPU perché ha fatto richiesta di una risorsa non disponibile) e i cambi di contesto involontari (quando un processo è stato sottratto alla CPU perché è scaduto il suo tempo o è stata esercitata la prelazione da un processo a priorità maggiore).

Leggi anche:  Linux, il cubo magico e il Black Friday di riprovaci.it

5.2 Criteri di scheduling

Esistono diversi criteri da considerare prima di scegliere l’algoritmo di scheduling “migliore”, tra i quali:

  • Utilizzo della CPU: Usare la CPU il 100% delle volte, in modo da renderla sempre attiva. Su un sistema reale, l’utilizzo della CPU dovrebbe variare dal 40% (leggermente caricato) al 90% (pesantemente caricato).

Il comando

top

su Linux mostra il carico della CPU.

  • Throughput: Numero di processi completati per unità di tempo. Può variare da 10 processi al secondo per brevi transazioni fino a ore per processo (ricorda che throughput è traducibile come produttività).
  • Tempo di completamento turnaround time: Tempo necessario per eseguire un processo dal momento di inserimento nella coda dei processi pronti fino al completamento, tenendo conto anche dei tempi di attesa di I/O. 
  • Tempo di attesa: La somma dei tempi d’attesa passati nella coda dei processi pronti per un particolare processo.
  • Tempo di risposta: Il tempo tra una richiesta e la prima risposta prodotta.

Anche se è auspicabile massimizzare l’utilizzo e la produttività della CPU e minimizzare tutti gli altri criteri, in generale si è interessati ad ottimizzare i valori medi (qualche volta ci si concentra sul ridurre al minimo il tempo di risposta).

Alcuni analisti suggeriscono di minimizzare la varianza del tempo di risposta rispetto al al tempo medio di risposta,  poiché si preferisce un sistema con tempo di risposta prevedibile al costo di una minore velocità, che un tempo medio di risposta ottimale ma incoerente.

5.3 Algoritmi di scheduling

Le seguenti sottosezioni spiegheranno diverse strategie di pianificazione comuni, osservando solo una singola CPU per un numero limitato di processi ideali.

5.3.1 Scheduling in ordine di arrivo first come first serve FCFS

FCFS è il più semplice algoritmo di scheduling senza prelazione da capire ed implementare, poiché basa la coda dei processi pronti su una coda FIFO (il primo processo ad entrare sarà il primo ad essere eseguito dalla CPU).

Purtroppo può produrre tempi medi di attesa molto lunghi, in particolare se il primo processo per arrivarci richiede molto tempo.

Per calcolare il tempo medio di attesa, basta considerare il ms di inizio del processo e sommarlo ai precedenti, quindi dividere il risultato della somma per il numero dei processi.

Ad esempio, considerare i tre processi seguenti:

ProcessiDurata della sequenza in millisecondi
P124
P23
P33
Tabella con 3 processi e relativa durata
Diagramma di Gantt per i tre processi con il FCFS

Nel diagramma di Gantt, il processo P1 arriva per primo, dopo 24 ms arriva P2, dopo 27 arriva P3. Il tempo medio di attesa per i tre processi è

Calcolo del tempo medio di attesa nel FCFS

considerato come un valore alto.

Diagramma di Gantt con i processi ordinati in base al tempo

Nel caso l’ordine fosse P2,P3,P1 allora, considerato il diagramma di Gantt, gli stessi tre processi hanno un tempo medio di attesa di

Tempo medio di attesa con ordinamento per brevità

Il tempo di esecuzione totale per le tre sequenze è lo stesso, ma nel secondo caso due dei tre processi finiscono prima, ritardando il processo più lungo per una piccola quantità di tempo.

Per questo motivo è sconsigliato l’uso del FCFS nei sistemi time sharing, dove ogni processo dispone della CPU ad intervalli regolari.

FCFS soffre, tra l’altro, del cosiddetto effetto convoglio, dove molti brevi processi attendono un lungo processo che occupa la CPU, causandone una riduzione su l’uso.

5.3.2 Scheduling per brevità shortes job first SJF

L’idea alla base dell’algoritmo SJF shortest job first (anche se dovrebbe essere più corretto chiamarlo shortest next CPU burst first poiché si esamina la lunghezza della successiva sequenza di operazioni attinenti al processo e non la sua lunghezza totale) è quella di scegliere il processo a più breve lunghezza da eseguire.

Supponiamo di avere 4 processi P1, P2, P3, P4:

ProcessiDurata della sequenza in millisecondi
P16
P28
P37
P43
Tabella con quattro processi e relativa durata
Diagramma di Gantt per i quattro processi considerati

Il tempo medio di attesa è

Tempo medio di attesa per i quattro processi nel SJF

invece di 10,25 ms per FCFS con gli stessi processi.

È possibile dimostrare che SJF è un ‘algoritmo di scheduling ottimale poiché minimizza il tempo d’attesa medio (basta pensare che sposta un processo breve prima di un processo lungo per non far aspettare troppo tempo), ma soffre di un problema importante, ovvero non esiste un modo per determinare la lunghezza della successiva sequenza di operazioni).

Una soluzione consiste nel prevedere la durata della prossima sequenza attraverso la media esponenziale:

Formula media esponenziale
Confronto tra i valori della media esponenziale e andamento reale

Notare che si da lo stesso peso sia alla storia passata (stima) che all’informazione del presente.

In questo schema la stima precedente contiene la cronologia di tutti i tempi precedenti e l’alfa funge da fattore di ponderazione per l’importanza relativa dei dati recenti rispetto alla storia passata. 

SJF può essere senza o con prelazione

  • Se SJF è senza prelazione, il processo in esecuzione permane nello stato di esecuzione anche se è presente un processo breve nella coda dei processi pronti. 
  • Se SJF è con prelazione il processo in esecuzione  viene sostituito se nella coda dei processi pronti è presente un processo breve. Lo SJF con prelazione viene talvolta definita shortest remaining time first.

Ad esempio, consideriamo 4 processi (P1,P2,P3,P4) con relativa durata della sequenza e istante di arrivo:

ProcessiIstante di arrivoDurata della sequenza in millisecondi
P18
P214
P329
P435
Tabella dei quattro processi con durata relativa e tempo di arrivo

Il tempo medio di attesa in questo caso è

a differenza di 7,75 ms per SJF senza prelazione  e degli 8,75 per FCFS.

Da notare che il processo P2 viene sostituito al termine della sua esecuzione con il processo P4.

5.3.3 Scheduling circolare round robin RR

È simile allo FCFS, ma introduce la prelazione e definisce, per ogni processo, dei limiti temporali d’uso della CPU, detti quanti di tempo o porzione di tempo (time slice), in genere da 10 a 100 ms.

Quando un processo passa allo stato di esecuzione, viene impostato un timer che generi un’interruzione allo scadere del quanto di tempo, quindi attivi il dispatcher.

Da questo punto possono verificarsi due situazioni:

  • Se il processo termina prima della scadenza (quanto), viene sostituito dalla CPU con il successivo processo nella coda dei processi pronti (come FCFS) .
  • Se scade il timer, questo invia l’interruzione al sistema operativo che esegue un cambio di contesto e sposta il processo attuale alla fine della coda dei processi pronti.
Leggi anche:  Inventor Professional 2020-Tutorial-S01E01-Panoramica del software

Il tempo medio di attesa può essere più lungo rispetto ad altri algoritmi.

Ad esempio, per tre processi (P1,P2,P3) che arrivano nello stesso istante, con un quanto di 4 ms

ProcessiDurata della sequenza in millisecondi
P124
P23
P33
Tre processi con rispettiva durata in ms

Il processo P1 viene eseguito nei primi 4 millisecondi (in un quanto di tempo), quindi a seguito dell’interruzione generata dal timer, è soggetto a prelazione e la CPU passa al processo successivo della coda dei processi pronti.

Visto che il processo P2 ha una durata minore rispetto al quanto, esaurito questo, si passa al processo P3 che presenta la medesima durata. Terminato anche il processo P3, si riparte con il processo P1 fintantoché non termina anche quest’ultimo. Calcoliamo ora il tempo di attesa medio:

  • Per il processo P1 si ha un’attesa di 6 (10-4)  millisecondi.
  • Per il processo P2 si ha un’attesa di 4 millisecondi.
  • Per il processo P3 si ha un’attesa di 7 millisecondi.

Quindi il tempo di attesa medio è

Tempo medio di attesa con il RR

Estendendo al caso generale, se nella coda dei processi pronti esistono n processi e q è il quanto di tempo, ciascun processo:

  • Ottiene  1/n-esimo del tempo di elaborazione della CPU in frazioni di unità temporali
  • Non deve attendere più di unità temporali per il suo successivo quanto di tempo.
  • Per 5 processi con quanto da 20 millisecondi, ogni processo userà 20 millisecondi ogni 100 millisecondi. 

Le prestazioni del RR sono sensibili al valore del quanto.

  •  Se il quanto è abbastanza grande (ad esempio 12 millisecondi), allora RR si riduce al FCFS
  • Se è molto piccolo, ogni processo ottiene 1/9 del tempo del processore e condivide equamente la CPU ma si ha un numero elevato di cambi di contesto. Ciò significa che minore è il tempo quantico, maggiore è il cambio di contesto

In  un sistema reale, però, pesa il sovraccarico per ogni cambio di contesto. La maggior parte dei sistemi moderni utilizza un quanto compreso tra 10 e 100 millisecondi e tempi di cambi di contesto nell’ordine di 10 microsecondi, quindi l’overhead è piccolo rispetto al tempo quantico.

Un altro fattore correlato al quanto è il tempo di completamento medio turnaround time relativo ad un insieme di processi che è ridotto al minimo se la maggior parte dei processi termina entro un tempo quantico.

Con 3 processi da 10 ms e quanto da 1 ms, il tempo di consegna medio è 29 ms mentre scende a 20 ms per quanto grande 10 ms.

Una regola empirica è che l’80% delle sequenze di operazioni dovrebbe essere inferiore al quanto di tempo.

5.3.4 Scheduling con priorità

È un algoritmo di scheduling basato sul concetto di priorità.

Ad ogni processo viene assegnata una priorità e il processo con priorità più alta viene eseguito per primo; Lo SJF risulta un suo caso particolare, perché SJF può essere visto come un algoritmo di scheduling con priorità dove la stessa priorità è l’inverso della lunghezza prevista della successiva sequenza di operazioni).

Le priorità sono implementate usando numeri interi entro un intervallo fisso, ma non esiste una convenzione concordata. Nel libro si accetta che più il numero della priorità è piccolo, maggiore è la priorità. 

ProcessiIstante di arrivoDurata della sequenza in millisecondiPriorità
P11103
P2211
P3324
P4415
P5552
Tabella di cinque processi con relativa durata temporale e istante di tempo di arrivo

Ad esempio, il seguente diagramma di Gantt si basa su questi tempi e priorità del processo e produce un tempo di attesa medio di 8,2 ms:

Le priorità possono essere assegnate internamente o esternamente.

Le priorità interne sono assegnate dal sistema operativo usando criteri come il tempo di burst medio, il rapporto tra attività CPU e di I/O, uso delle risorse di sistema e altri fattori disponibili per il kernel.

Le priorità esterne sono assegnate dagli utenti, in base all’importanza del lavoro, alle commissioni pagate, alla politica, ecc.

Gerarchia di priorità

Lo scheduling con priorità può essere con o senza prelazione. Lo scheduling con priorità con prelazione,  soffre di un grave problema detto attesa indefinita starvation , in cui un’attività a bassa priorità può attendere per sempre perché ci sono sempre altri lavori che hanno priorità più alta.

I processi a bassa priorità rischiano di dover attendere un alleggerimento del carico di sistema o di perdersi quando il sistema si arresterà in modo anomalo.

È famoso l’esempio dell’ IBM 7094 al MIT, che al momento del suo arresto, nel 1973, presentava un processo del 1967 non ancora eseguito.

Una soluzione a questo problema è l’aumento graduale delle priorità o invecchiamento aging, in cui le priorità dei processi aumentano all’aumentare dell’attesa. In base a questo schema, un lavoro a bassa priorità alla fine raggiungerà una priorità abbastanza elevata per essere eseguito.

5.3.5 Scheduling a code multilivello

Quando i processi possono essere facilmente classificati, è possibile stabilire più code separate, ciascuna che implementa l’algoritmo di scheduling risulti più appropriato per la tipologia di processo.

Suddividendo i processi in base ai requisiti di tempo di risposta si hanno due tipi:

  1. processi in primo piano (interattivi o foreground)
  2. processi in background (batch)

I processi in primo piano (interattivi), potrebbero essere gestiti attraverso l’algoritmo di scheduling circolare (cioè il round robin RR), mentre i processi in background (batch) potrebbero essere gestiti attraverso l’algoritmo di scheduling FCFS.

Lo scheduling deve essere eseguito anche tra le code, generalmente attraverso un algoritmo di scheduling a priorità con prelazione (un processo in una coda con priorità bassa non può iniziare se esistono processi nelle code a maggiore priorità) oppure definendo porzioni di tempo (RR) per le code (la coda dei processi in background può occupare la CPU per un tempo minore rispetto alla coda dei processi interattivi foreground).

Nota che, in questo algoritmo, i processi non possono passare da una coda all’altra. Una volta assegnata una coda al processo, questo rimane nella coda fino al termine.

5.3.6 Scheduling a code multilivello con retroazione

È simile allo scheduling a code multilivello ma consente di spostare i processi su altre code:

  • Un processo CPU bound troppo lungo viene spostato in una coda a bassa priorità, mentre processi I/O bound e interattivi sono mantenuti in code con priorità maggiore.
  • Un processo in attesa da troppo tempo in una coda a bassa priorità viene spostato in una coda a maggiore priorità (aging per evitare attesa indefinita).
Leggi anche:  TestDisk: recuperare tutti i dati dall'hard disk danneggiato

Ad esempio, se si hanno tre code (0,1,2), lo scheduler esegue tutti i processi della coda 0 per poi eseguire quelli della coda 1, poi quelli rimanenti della coda 2. Il diritto di prelazione viene esercitato da una coda rispetto alle restanti con priorità minore (la coda 1 ha prelazione sulla coda 2).

Se un processo della coda 0 non termina allo scadere del suo quanto (ad esempio 8 ms), viene spostato alla fine della coda 1, quindi dovrà attendere che si esauriscano i processi della coda 0 per poi essere eseguito in un quanto (ad esempio 16 ms). Se non termina neanche in questo caso, viene spostato nella coda 2, dove si usa il FCFS. Tutti i processi vengono serviti rapidamente, poiché meno lungo è il processo, maggiore è la sua priorità.

Tale algoritmo è il più flessibile (ottimo per ogni situazione dato che è generico) ma è il più complicato da implementare a causa di tutti i parametri regolabili.

Alcuni dei parametri che definiscono uno di questi sistemi includono:

  • Il numero di code.
  • L’algoritmo di scheduling per ogni coda.
  • I metodi utilizzati per aggiornare o degradare i processi da una coda all’altra. 
  • Il metodo utilizzato per determinare a quale coda si assegna il processo.

5.4 Scheduling dei thread

Nei sistemi operativi dove sono previsti i thread, lo scheduler a breve termine pianifica solo i thread del kernel. I thread utente sono relazionati ai thread del kernel grazie a strumenti offerti dalla libreria thread (il lightweight process ne è un esempio di relazione indiretta).

5.4.1 Ambito di conflitto

L’ambito della contesa si riferisce all’ambito in cui i thread competono per l’uso di CPU fisiche. 

  • Sui sistemi che implementano thread molti-a-uno e molti-a-molti, si parla di Process Contention Scope, PCS , poiché si verifica la concorrenza tra thread che fanno parte dello stesso processo, concorrenza gestita dalla libreria dei thread in genere con priorità.
  • Sui sistemi che implementano thread uno a uno, si  parla di System Contention Scope SCS, quando lo scheduler di sistema pianifica i thread del kernel per l’esecuzione su una o più CPU. Windows e Linux usano solo SCS.

5.4.2 Pianificazione Pthread

La libreria Pthread consente di specificare la contesa dell’ambito:

  • PTHREAD_SCOPE_PROCESS pianifica i thread utilizzando PCS.
    • PTHREAD_SCOPE_SYSTEM pianifica i thread utilizzando SCS, dunque si associa ad ogni thread utente un  processo leggero, implementando in modo efficace un modello one-to-one.

I metodi 

  • pthread_attr_getscope() 
  • pthread_attr_setscope() 

forniscono rispettivamente la determinazione e l’impostazione della contesa dell’ambito. Nell’esempio vengono creati 5 thread eseguiti con modello di scheduling SCS.

5.5 Scheduling per sistemi multiprocessore

Quando sono disponibili più processori, la pianificazione diventa più complicata, visto che c’è più di una CPU che deve essere tenuta occupata e usata efficacemente. I sistemi multiprocessore possono essere eterogenei (diversi tipi di CPU) o omogenei (tutti dello stesso tipo di CPU) e la distribuzione del carico ruota attorno al bilanciamento del carico tra più processori. 

5.5.1 Approcci allo scheduling per multiprocessori

Un primo approccio è la multielaborazione asimmetrica, dove un processore è il master server che controlla tutte le attività di sistema, decisioni ed elaborazioni I/O, mentre i rimanenti eseguono solo il codice utente. Lo svantaggio è dato dal degrado delle prestazioni per via del master server, unico a poter accedere alle strutture dati di sistema.

Un altro approccio è la multielaborazione simmetrica SMP in cui ciascun processore si autogestisce e ogni scheduler selezioni un thread  da una coda dei processi pronti comune o da code dei processi pronti separate per ciascun processore. Tutti i moderni sistemi operativi lo supportano.

5.5.2 Predilezione dei processori

I processori contengono memoria cache, che accelera gli accessi ripetuti alle stesse posizioni di memoria.

Se un processo dovesse passare da un processore a un altro ogni volta che otteneva un intervallo di tempo, i dati nella cache (per quel processo) dovrebbero essere invalidati e ricaricati dalla memoria principale, annullando così il vantaggio della cache.

Pertanto i sistemi SMP tentano di mantenere i processi sullo stesso processore, tramite l’ affinità del processore.

L’affinità soft si verifica quando il sistema tenta di mantenere i processi sullo stesso processore ma non fornisce garanzie.

Linux e alcuni altri sistemi operativi supportano una forte affinità, in cui un processo specifica che non deve essere spostato tra i processori.

L’architettura della memoria principale può anche influenzare l’affinità del processo, se particolari CPU hanno un accesso più rapido alla memoria sullo stesso chip o scheda rispetto ad altra memoria caricata altrove. (Accesso alla memoria non uniforme, NUMA.)

Come mostrato di seguito, se un processo ha un’affinità per una particolare CPU, allora dovrebbe essere preferibilmente assegnato alla memoria in aree di accesso rapido “locali”.

5.5.3 Bilanciamento del carico

Un obiettivo importante in un sistema multiprocessore è bilanciare il carico tra processori, in modo che un processore non rimanga inattivo mentre un altro è sovraccarico. I sistemi che utilizzano una coda dei processi pronti comune sono naturalmente autobilanciati e non richiedono alcuna gestione speciale. La maggior parte dei sistemi, tuttavia, mantiene le code dei processi pronti separate per ciascun processore. Il bilanciamento può essere ottenuto tramite migrazione push o migrazione pull, modelli che non si escludono a vicenda:

  • La migrazione push comporta un processo separato che viene eseguito periodicamente (ad es. Ogni 200 millisecondi) e sposta i processi da processori a carico pesante a processi meno caricati.
  • La migrazione pull si presenta quando un processore inattivo prende i processi dalle code dei processi pronti di processori sovraccarichi.

Se l’articolo vi piace vi invito a condividerlo con tutti gli interessati.

Per domande, dubbi o perplessità, lasciate qua sotto un commento, vi risponderò il prima possibile.


Vi ricordo di iscrivervi al sito tramite mail e di seguirci sui nostri Social: 
Facebook , Instagram , TelegramYouTube e Twitter

Al prossimo articolo!

Author: Alessandro Giaquinto

Rispondi