Inizio priorita' di I/O

[gapil.git] / prochand.tex

diff --git a/prochand.tex b/prochand.tex
index 510e69ac8f11c3262149395d7b955f753e1c93cc..da1d5020ba81e2a5101fa70697eca06797bb5a5f 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -631,7 +631,7 @@ comune dopo l'esecuzione di una \func{fork} 
 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
 \item il valori di \textit{nice}, le priorità real-time e le affinità di
   processore (vedi sez.~\ref{sec:proc_sched_stand},
 \item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
 \item il valori di \textit{nice}, le priorità real-time e le affinità di
   processore (vedi sez.~\ref{sec:proc_sched_stand},

-  sez.~\ref{sec:proc_real_time} e sez.\ref{sec:proc_sched_multiprocess});
+  sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});

 \item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
 \end{itemize*}
 Le differenze fra padre e figlio dopo la \func{fork} invece sono:
 \item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
 \end{itemize*}
 Le differenze fra padre e figlio dopo la \func{fork} invece sono:


@@ -648,7 +648,6 @@ Le differenze fra padre e figlio dopo la \func{fork} invece sono:
   per il figlio vengono cancellati.
 \end{itemize*}
 
   per il figlio vengono cancellati.
 \end{itemize*}
 

-

 Una seconda funzione storica usata per la creazione di un nuovo processo è
 \func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
 semantica e gli stessi errori; la sola differenza è che non viene creata la
 Una seconda funzione storica usata per la creazione di un nuovo processo è
 \func{vfork}, che è esattamente identica a \func{fork} ed ha la stessa
 semantica e gli stessi errori; la sola differenza è che non viene creata la


@@ -666,8 +665,9 @@ venne introdotta in BSD per migliorare le prestazioni.
 
 Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
 perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
 
 Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
 perdita di prestazioni è assolutamente trascurabile, e l'uso di questa

-funzione (che resta un caso speciale della system call \func{\_\_clone}) è
-deprecato; per questo eviteremo di trattarla ulteriormente.
+funzione, che resta un caso speciale della system call \func{clone} (che
+tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
+questo eviteremo di trattarla ulteriormente.

 
 
 \subsection{La conclusione di un processo}
 
 
 \subsection{La conclusione di un processo}


@@ -742,8 +742,6 @@ che sia cos
 terminato; si potrebbe avere cioè quello che si chiama un processo
 \textsl{orfano}. 
 
 terminato; si potrebbe avere cioè quello che si chiama un processo
 \textsl{orfano}. 
 

-% TODO verificare il reparenting
-

 Questa complicazione viene superata facendo in modo che il processo orfano
 venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
 termina, il kernel controlla se è il padre di altri processi in esecuzione: in
 Questa complicazione viene superata facendo in modo che il processo orfano
 venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
 termina, il kernel controlla se è il padre di altri processi in esecuzione: in


@@ -2087,16 +2085,16 @@ compila con il flag \cmd{-ansi}, 
 scrivere codice portabile.
 
  
 scrivere codice portabile.
 
  

-\section{La gestione della priorità di esecuzione}
+\section{La gestione della priorità dei processi}

 \label{sec:proc_priority}
 
 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
 lo \itindex{scheduler} \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
 \label{sec:proc_priority}
 
 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
 lo \itindex{scheduler} \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.
+gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
+per l'accesso a disco) divenute disponibili con i kernel più recenti.

 
 

-% TODO: rivedere alla luce degli aggiornamenti del 2.6 (man sched_setscheduler)

 
 \subsection{I meccanismi di \textit{scheduling}}
 \label{sec:proc_sched}
 
 \subsection{I meccanismi di \textit{scheduling}}
 \label{sec:proc_sched}


@@ -2172,7 +2170,8 @@ fintanto che esso si trova in uno qualunque degli altri stati.
                                     2.6.25, sostanzialmente identico
                                     all'\textbf{Uninterrutible Sleep} con la
                                     sola differenza che il processo può
                                     2.6.25, sostanzialmente identico
                                     all'\textbf{Uninterrutible Sleep} con la
                                     sola differenza che il processo può

-                                    terminato (con \const{SIGKILL}).\\ 
+                                    terminato con \const{SIGKILL} (usato per
+                                    lo più per NFS).\\ 

     \hline
   \end{tabular}
   \caption{Elenco dei possibili stati di un processo in Linux, nella colonna
     \hline
   \end{tabular}
   \caption{Elenco dei possibili stati di un processo in Linux, nella colonna


@@ -2181,8 +2180,6 @@ fintanto che esso si trova in uno qualunque degli altri stati.
   \label{tab:proc_proc_states}
 \end{table}
 
   \label{tab:proc_proc_states}
 \end{table}
 

-% TODO nel 2.6.25 è stato aggiunto TASK_KILLABLE, da capire dova va messo.
-

 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
 dello scopo del programma non è detto neanche che sia la più importante (molti
 Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle
 risorse che sono necessarie per l'esecuzione di un programma, e a seconda
 dello scopo del programma non è detto neanche che sia la più importante (molti


@@ -2768,13 +2765,22 @@ real-time, e serve a far s
 da essere rimesso in coda alla lista dei processi con la stessa priorità per
 permettere ad un altro di essere eseguito; se però il processo è l'unico ad
 essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano
 da essere rimesso in coda alla lista dei processi con la stessa priorità per
 permettere ad un altro di essere eseguito; se però il processo è l'unico ad
 essere presente sulla coda l'esecuzione non sarà interrotta. In genere usano

-questa funzione i processi in modalità \textit{fifo}, per permettere
+questa funzione i processi con politica \const{SCHED\_FIFO}, per permettere

 l'esecuzione degli altri processi con pari priorità quando la sezione più
 urgente è finita.
 
 l'esecuzione degli altri processi con pari priorità quando la sezione più
 urgente è finita.
 

-% TODO: con il 2.6.23 il comportamento è stato leggermente modificato ed è
-% stato introdotto /proc/sys/kernel/sched_compat_yield da mettere a 1 per aver
-% la compatibilità con il precedente.
+La funzione può essere utilizzata anche con processi che usano lo scheduling
+ordinario, ma in questo caso il comportamento non è ben definito, e dipende
+dall'implementazione. Fino al kernel 2.6.23 questo comportava che i processi
+venissero messi in fondo alla coda di quelli attivi, con la possibilità di
+essere rimessi in esecuzione entro breve tempo, con l'introduzione del
+\textit{Completely Fair Scheduler} questo comportamento è cambiato ed un
+processo che chiama la funzione viene inserito nella lista dei processi
+inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
+  ripristinare un comportamento analogo al precedente scrivendo il valore 1
+  nel file \texttt{/proc/sys/kernel/sched\_compat\_yield}.}
+
+

 
 \subsection{Il controllo dello \textit{scheduler} per i sistemi
   multiprocessore}
 
 \subsection{Il controllo dello \textit{scheduler} per i sistemi
   multiprocessore}


@@ -2884,8 +2890,8 @@ utilizzato per un compito importante (ad esempio per applicazioni real-time o
 la cui risposta è critica) e si vuole la massima velocità, con questa
 interfaccia diventa possibile selezionare gruppi di processori utilizzabili in
 maniera esclusiva.  Lo stesso dicasi quando l'accesso a certe risorse (memoria
 la cui risposta è critica) e si vuole la massima velocità, con questa
 interfaccia diventa possibile selezionare gruppi di processori utilizzabili in
 maniera esclusiva.  Lo stesso dicasi quando l'accesso a certe risorse (memoria

-o periferiche) può avere un costo diverso a seconda del processore (come
-avviene nelle architetture NUMA).
+o periferiche) può avere un costo diverso a seconda del processore, come
+avviene nelle architetture NUMA (\textit{Non-Uniform Memory Access}).

 
 Infine se un gruppo di processi accede alle stesse risorse condivise (ad
 esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
 
 Infine se un gruppo di processi accede alle stesse risorse condivise (ad
 esempio una applicazione con più \itindex{thread} \textit{thread}) può avere


@@ -2967,6 +2973,25 @@ non avranno alcun risultato effettivo.
 \itindend{CPU~affinity}
 
 
 \itindend{CPU~affinity}
 
 

+\subsection{Le priorità per le operazioni di I/O}
+\label{sec:io_priority}
+
+A lungo l'unica priorità usata per i processi è stata quella relativa
+all'assegnazione dell'uso del processore. Ma il processore non è l'unica
+risorsa che i processi devono contendersi, un'altra, altrettanto importante
+per le prestazioni, è quella dell'accesso a disco. Per questo motivo sono
+stati introdotti diversi \textit{I/O scheduler} in grado di distribuire in
+maniera opportuna questa risorsa ai vari processi. Fino al kernel 2.6.17 era
+possibile soltanto decidere le politiche di gestione scegliendo un diverso
+\textit{I/O scheduler}  
+
+
+%TODO trattare le priorità di I/O
+% vedi man ioprio_set e Documentation/block/ioprio.txt
+
+%TODO trattare le funzionalità per il NUMA
+% vedi man numa e le pagine di manuale relative
+% vedere anche dove metterle...

 
 \section{Problematiche di programmazione multitasking}
 \label{sec:proc_multi_prog}
 
 \section{Problematiche di programmazione multitasking}
 \label{sec:proc_multi_prog}


@@ -3176,7 +3201,8 @@ varie funzioni di libreria, che sono identificate aggiungendo il suffisso
 % LocalWords:  infop ALL WEXITED WSTOPPED WNOWAIT signo CLD EXITED KILLED page
 % LocalWords:  CONTINUED sources forking Spawned successfully executing exiting
 % LocalWords:  next cat for COMMAND pts bash defunct TRAPPED DUMPED Killable PR
 % LocalWords:  infop ALL WEXITED WSTOPPED WNOWAIT signo CLD EXITED KILLED page
 % LocalWords:  CONTINUED sources forking Spawned successfully executing exiting
 % LocalWords:  next cat for COMMAND pts bash defunct TRAPPED DUMPED Killable PR

-% LocalWords:  SIGKILL static RLIMIT preemption PREEMPT VOLUNTARY IDLE
+% LocalWords:  SIGKILL static RLIMIT preemption PREEMPT VOLUNTARY IDLE RTPRIO
+% LocalWords:  Completely Fair compat Uniform

 
 %%% Local Variables: 
 %%% mode: latex
 
 %%% Local Variables: 
 %%% mode: latex