X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=4c16fe24584e65fc4321a5a33012e3a4adcc603d;hp=4eb3d74603609dbed04093089a5cf81e3d6bd93d;hb=607aae2f62d086e9c71d6a571bbbb6908631207c;hpb=327a8452b33c9626ebec4cfe6c9d6daad54f4b19 diff --git a/prochand.tex b/prochand.tex index 4eb3d74..4c16fe2 100644 --- a/prochand.tex +++ b/prochand.tex @@ -290,12 +290,12 @@ il processo figlio continuano ad essere eseguiti normalmente alla istruzione seguente la \func{fork}; il processo figlio è però una copia del padre, e riceve una copia dei segmenti di testo, stack e dati (vedi \secref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del -padre, ma la memoria è copiata, non condivisa\footnote{In generale il segmento +padre, ma la memoria è copiata, non condivisa,\footnote{In generale il segmento di testo, che è identico, è condiviso e tenuto in read-only, Linux poi utilizza la tecnica del \textit{copy-on-write}, per cui la memoria degli altri segmenti viene copiata dal kernel per il nuovo processo solo in caso di scrittura, rendendo molto più efficiente il meccanismo della creazione di - un nuovo processo.}, pertanto padre e figlio vedono variabili diverse. + un nuovo processo.} pertanto padre e figlio vedono variabili diverse. La differenza che si ha nei due processi è che nel processo padre il valore di ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre @@ -1806,10 +1806,81 @@ 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} assegna la CPU ai vari processi attivi, illustrando le -varie funzioni che permettono di leggere e modificare le priorità di -esecuzione dei programmi. - +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 prendremo in esame i vari meccanismi +con cui viene gestita l'assgnazione del tempo di CPU, ed illustreremo le varie +funzioni di gestione. + + +\subsection{I meccanismi di \textit{scheduling}} +\label{sec:proc_sched} + +La scelta di un meccanismo che sia in grado di distribuire in maniera efficace +il tempo di CPU per l'esecuzione dei processi è sempre una questione delicata, +ed oggetto di numerose ricerche; in ogni caso essa dipende in maniera +essenziale anche dal tipo di utilizzo che deve essere fatto del sistema. + +La cosa è resa ancora più complicata dal fatto che con sistemi +multi-processore si introduce anche la complessità 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 + determininare 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 di può pensare sempre +alla risorsa tempo di esecuzione, governata dagli stessi mecca, che nel caso +di più processori sarà a disposizione di più di un processo alla volta. + +Si tenga presente inoltre 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 politica tradizionale di scheduling di Unix (che tratteremo in +\secref{sec:proc_sched_stand}) è sempre stata basata su delle priorità +dinamiche, che assicurassaro che tutti i processi, anche i meno importanti, +potessero ricevere un po' di tempo di CPU. + +Lo standard POSIX però per tenere conto dei sistemi real-time,\footnote{per + sistema real-time si intende un sistema in grado di eseguire operazioni in + tempo reale; in genere si tende a distinguere fra l'\textit{hard real-time} + in cui è necessario che i tempi di esecuzione di un programma siano + determinabili con certezza assoluta, come nel caso di meccanismi di + controllo di macchine, dove uno sforamento dei tempi avrebbe conseguenze + disastrose, e \textit{soft-real-time} in cui un occasionale sforamento è + ritenuto accettabile.} in cui è vitale che i processi in che devono essere +eseguiti in un determinato momento non debbano aspettare la conclusione di un +altri processi che non hanno questa necessità, ha introdotto il concetto di +\textsl{priorità assoluta}, chimata anche \textsl{priorità statica}, in +contrapposizione con la normale priorità dinamica. + +Il concetto di prorità assoluta dice che quando due processi si contendono +l'esecuzione, vince sempre quello con la priorità assoluta più alta, anche, +grazie al \textit{prehemptive scheduling}, se l'altro è in esecuzione. +Ovviamente questo avviene solo per i processi che sono pronti per essere +eseguiti (cioè nello stato \textit{runnable}\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}. + +Questa viene in genere indicata con un numero + + + + +\subsection{Il meccanismo di \textit{scheduling} standard} +\label{sec:proc_sched_stand} + +In Linux tutti i processi hanno sostanzialmente la stessa priorità; benché sia +possibile specificare una priorità assoluta secondo lo standard POSIX +(argomento che tratteremo più avanti) l'uso comune segue quello che è il +meccanismo tradizionale con cui i sistemi