From: Simone Piccardi Date: Mon, 25 Mar 2002 18:40:09 +0000 (+0000) Subject: Rimaneggiata ancora la parte sullo scheduler, con ancora piu` casino. X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=e83be2da028abd74433573a4b17299badedb04e1;p=gapil.git Rimaneggiata ancora la parte sullo scheduler, con ancora piu` casino. --- diff --git a/biblio.bib b/biblio.bib index 681e3ef..3004c7d 100644 --- a/biblio.bib +++ b/biblio.bib @@ -79,8 +79,7 @@ OPTannote = {} } @Book{glibc, - author = {Sandra Loosemore with Richard M. Stallman, -Roland McGrath, Andrew Oram, and Ulrich Drepper}, + author = {Sandra Loosemore Richard M. Stallman Roland McGrath Andrew Oram and Ulrich Drepper}, editor = {Free Software Foundation}, title = {The GNU C Library Reference Manual}, publisher = {Free Software Foundation}, diff --git a/fileunix.tex b/fileunix.tex index fbc65cd..0551441 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -549,7 +549,7 @@ In realt \macro{EAGAIN} non sono errori. La prima si verifica quando la \func{read} è bloccata in attesa di dati in ingresso e viene interrotta da un segnale; in tal caso l'azione da prendere è quella di rieseguire la funzione. Torneremo -sull'argomento in \secref{sec:signal_xxx}. +sull'argomento in \secref{sec:sig_gen_beha}. La seconda si verifica quando il file è in modalità non bloccante e non ci sono dati in ingresso: la funzione allora ritorna immediatamente con un errore diff --git a/prochand.tex b/prochand.tex index 4bd9a46..73f2e7f 100644 --- a/prochand.tex +++ b/prochand.tex @@ -133,7 +133,8 @@ riprese), Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che decide quale processo mettere in esecuzione; esso viene eseguito ad ogni -system call ed ad ogni interrupt, (ma può essere anche attivato +system call ed ad ogni interrupt,\footnote{più in una serie di altre + occasioni. NDT completare questa parte.} (ma può essere anche attivato esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato periodicamente, generando un interrupt periodico secondo la frequenza specificata dalla costante \macro{HZ}, definita in \file{asm/param.h}. Il @@ -1821,11 +1822,9 @@ quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag \label{sec:proc_priority} In questa sezione tratteremo più approfonditamente i meccanismi con il quale -lo \textit{scheduler}\footnote{che è la parte del kernel che si occupa di - stabilire quale processo dovrà essere posto in esecuzione.} assegna la CPU -ai vari processi attivi. In particolare prenderemo in esame i vari meccanismi -con cui viene gestita l'assegnazione del tempo di CPU, ed illustreremo le -varie funzioni di gestione. +lo \textit{scheduler} assegna la CPU ai vari processi attivi. In particolare +prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del +tempo di CPU, ed illustreremo le varie funzioni di gestione. \subsection{I meccanismi di \textit{scheduling}} @@ -1836,29 +1835,47 @@ il tempo di CPU per l'esecuzione dei processi ed oggetto di numerose ricerche; in ogni caso essa dipende in maniera essenziale anche dal tipo di utilizzo che deve essere fatto del sistema. -Si tenga presente comunque che l'utilizzo della CPU è soltanto una delle -risorse (insieme alla memoria e all'accesso alle periferiche) che sono -necessarie per l'esecuzione di un programma, e spesso non è neanche la più -importante. Per questo non è affatto detto che dare ad un programma la massima -priorità di esecuzione abbia risultati significativi in termini di -prestazioni. La caratteristica specifica di un sistema multitasking come Linux è quella del cosiddetto \textit{prehemptive multitasking}: questo significa che al contrario di altri sistemi (che usano invece il cosiddetto \textit{cooperative multitasking}) non sono i singoli processi, ma il kernel stesso a decidere quando la CPU deve essere passata ad un altro processo. Come accennato in -\secref{sec:proc_hierarchy} questa scelta viene eseguita dallo -\textit{scheduler} il cui scopo è quello di distribuire al meglio il tempo di -CPU fra i vari processi. +\secref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione +apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di +distribuire al meglio il tempo di CPU fra i vari processi. -Il Linux un processo può trovarsi in uno degli stati riportati in +La cosa è resa ancora più complicata dal fatto che con le architetture +multi-processore si introduce anche la problematica dovuta alla scelta di +quale sia la CPU più opportuna da utilizzare.\footnote{nei processori moderni + la presenza di ampie cache può rendere poco efficiente trasferire + l'esecuzione di un processo da una CPU ad un'altra, per cui occorrono + meccanismi per determinare quale è la migliore scelta fra le diverse CPU.} +Tutto questo comunque appartiene alle sottigliezze dell'implementazione del +kernel, e dal punto di vista dei programmi che girano in user space, anche +quando si hanno più processori (e dei processi che sono eseguiti davvero in +contemporanea), si può pensare alle politiche di scheduling come concernenti +la risorsa \textsl{tempo di esecuzione}, la cui assegnazione sarà governata +dagli stessi meccanismi di scelta di priorità, solo che nel caso di più +processori sarà a disposizione di più di un processo alla volta. + +I processi non devono solo eseguire del codice, ad esempio molto spesso +saranno impegnati in operazioni di I/O, possono venire bloccati da un +comando dal terminale, sospesi per un certo periodo di tempo. In tutti questi +casi la CPU diventa disponibile ed è compito dello kernel provvedere a mettere +in esecuzione un altro processo. +Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del +processo , + +In Linux un processo può trovarsi in uno degli stati riportati in +\tabref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato +\textit{runnable} concorrono per l'esecuzione. Questo vuol di \begin{table}[htb] \centering - \begin{tabular}[c]{|l|c|p{8cm}|} + \begin{tabular}[c]{|p{3cm}|c|p{8cm}|} \hline \textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\ \hline @@ -1876,40 +1893,27 @@ Il Linux un processo pu terminazione non è ancora stato letto dal padre. \\ \hline \end{tabular} - \caption{Tabella degli stati possibili per processo in Linux, si sono - riportati nella colonna \texttt{STAT} i valori dello stato ottenibili - dall'output del comando \cmd{ps}.} + \caption{Elenco dei possibili stati di un processo in Linux, nella colonna + \texttt{STAT} si è riportata la corripondente lettera usata dal comando + \cmd{ps} nell'omonimo campo.} \label{tab:proc_proc_states} \end{table} +Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle +risorse che sono necessarie per l'esecuzione di un programma, e spesso non è +neanche la più importante. Per questo motivo non è affatto detto che dare ad +un programma la massima priorità di esecuzione abbia risultati significativi +in termini di prestazioni. -Una delle caratteristiche c -,\footnote{lo stato di un processo - è riportato nel campo \texttt{STAT} dell'output del comando \cmd{ps}, - abbiamo già visto che lo stato di \textit{zombie} è indicato con \texttt{Z}, - gli stati \textit{runnable}, \textit{sleep} e di I/O (\textit{uninteruttible - sleep}) sono invece indicati con \texttt{R}, \texttt{S} e \texttt{D}.}) -la priorità assoluta viene invece ignorata per quelli che sono bloccati su una -richiesta di I/O o in stato di \textit{sleep} -La cosa è resa ancora più complicata dal fatto che con le architetture -multi-processore si introduce anche la problematica dovuta alla scelta di -quale sia la CPU più opportuna da utilizzare.\footnote{nei processori moderni - la presenza di ampie cache può rendere poco efficiente trasferire - l'esecuzione di un processo da una CPU ad un'altra, per cui occorrono - meccanismi per determinare quale è la migliore scelta fra le diverse CPU.} -Tutto questo comunque appartiene alle sottigliezze dell'implementazione del -kernel, e dal punto di vista dei programmi che girano in user space, anche -quando si hanno più processori (e dei processi che sono eseguiti davvero in -contemporanea), si può pensare alle politiche di scheduling come concernenti -la risorsa \textsl{tempo di esecuzione}, la cui assegnazione sarà governata -dagli stessi meccanismi di scelta di priorità, solo che nel caso di più -processori sarà a disposizione di più di un processo alla volta. +Una delle caratteristiche c +la priorità assoluta viene invece ignorata per quelli che sono bloccati su una +richiesta di I/O o in stato di \textit{sleep} @@ -1951,6 +1955,7 @@ assoluta nel qual caso un processo avr priorità inferiore che saranno eseguiti solo quando quest'ultimo non avrà bisogno della CPU. + \subsection{Il meccanismo di \textit{scheduling} standard} \label{sec:proc_sched_stand} @@ -2035,7 +2040,7 @@ qualunque momento, e le operazioni di un eventuale \textit{signal handler} sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche il solo accesso o l'assegnazione di una variabile possono non essere più operazioni atomiche (torneremo su questi aspetti in -\secref{sec:sign_control}). +\secref{sec:sig_control}). In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t}, il cui accesso è assicurato essere atomico. In pratica comunque si può