meccanismo è detto \textsl{paginazione} (o \textit{paging}), ed è uno dei
compiti principali del kernel.
+\itindbeg{page~fault}
+
Quando un processo cerca di accedere ad una pagina che non è nella memoria
-reale, avviene quello che viene chiamato un \itindex{page~fault} \textit{page
- fault}; la gestione della memoria genera un'interruzione e passa il
-controllo al kernel il quale sospende il processo e si incarica di mettere in
-RAM la pagina richiesta, effettuando tutte le operazioni necessarie per
-reperire lo spazio necessario, per poi restituire il controllo al processo.
+reale, avviene quello che viene chiamato un \textit{page fault}; la gestione
+della memoria genera un'interruzione e passa il controllo al kernel il quale
+sospende il processo e si incarica di mettere in RAM la pagina richiesta,
+effettuando tutte le operazioni necessarie per reperire lo spazio necessario,
+per poi restituire il controllo al processo.
Dal punto di vista di un processo questo meccanismo è completamente
trasparente, e tutto avviene come se tutte le pagine fossero sempre
dovuti all'intervento del kernel, qualora sia necessario reperire pagine
riposte nella \textit{swap}.
+\itindend{page~fault}
+
Normalmente questo è il prezzo da pagare per avere un multitasking reale, ed
in genere il sistema è molto efficiente in questo lavoro; quando però ci siano
esigenze specifiche di prestazioni è possibile usare delle funzioni che
chiamata una \itindex{segment~violation} \textit{segment violation}. Se si
tenta cioè di leggere o scrivere con un indirizzo per il quale non esiste
un'associazione nella memoria virtuale, il kernel risponde al relativo
-\itindex{page~fault} \textit{page fault} mandando un segnale \signal{SIGSEGV}
-al processo, che normalmente ne causa la terminazione immediata.
+\textit{page fault} mandando un segnale \signal{SIGSEGV} al processo, che
+normalmente ne causa la terminazione immediata.
È pertanto importante capire come viene strutturata la memoria virtuale di un
processo. Essa viene divisa in \textsl{segmenti}, cioè un insieme contiguo di
questo tipo di errori usando la variabile di ambiente \envvar{MALLOC\_CHECK\_}
che quando viene definita mette in uso una versione meno efficiente delle
funzioni suddette, che però è più tollerante nei confronti di piccoli errori
-come quello dei \itindex{double~free} \textit{double~free} o i
-\itindex{buffer~overrun} \textit{buffer overrun} di un byte.\footnote{uno
- degli errori più comuni, causato ad esempio dalla scrittura di una stringa
- di dimensione pari a quella del buffer, in cui ci si dimentica dello zero di
- terminazione finale.} In particolare:
+come quello dei \itindex{double~free} \textit{double~free} o i \textit{buffer
+ overrun} di un byte.\footnote{uno degli errori più comuni, causato ad
+ esempio dalla scrittura di una stringa di dimensione pari a quella del
+ buffer, in cui ci si dimentica dello zero di terminazione finale.} In
+particolare:
\begin{itemize*}
\item se la variabile è posta a $0$ gli errori vengono ignorati;
\item se la variabile è posta a $1$ viene stampato un avviso sullo
Siccome la richiesta di un \textit{memory lock} da parte di un processo riduce
la memoria fisica disponibile nel sistema per gli altri processi, questo ha un
evidente impatto su tutti gli altri processi, per cui fino al kernel 2.6.9
-solo un processo dotato di privilegi amministrativi (la \itindex{capabilities}
-\textit{capability} \const{CAP\_IPC\_LOCK}, vedi
-sez.~\ref{sec:proc_capabilities}) aveva la capacità di bloccare una pagina di
-memoria.
+solo un processo dotato di privilegi amministrativi (la \textit{capability}
+\const{CAP\_IPC\_LOCK}, vedi sez.~\ref{sec:proc_capabilities}) aveva la
+capacità di bloccare una pagina di memoria.
A partire dal kernel 2.6.9 anche un processo normale può bloccare la propria
memoria\footnote{la funzionalità è stata introdotta per non essere costretti a
\const{MCL\_FUTURE} ci si può limitare a tutte le pagine allocate a partire
dalla chiamata della funzione.
-In ogni caso un processo real-time che deve entrare in una
+In ogni caso un processo \textit{real-time} che deve entrare in una
\index{sezione~critica} sezione critica deve provvedere a riservare memoria
sufficiente prima dell'ingresso, per scongiurare l'occorrenza di un eventuale
-\itindex{page~fault} \textit{page fault} causato dal meccanismo di
-\itindex{copy~on~write} \textit{copy on write}. Infatti se nella
-\index{sezione~critica} sezione critica si va ad utilizzare memoria che non è
-ancora stata riportata in RAM si potrebbe avere un \itindex{page~fault}
-\textit{page fault} durante l'esecuzione della stessa, con conseguente
-rallentamento (probabilmente inaccettabile) dei tempi di esecuzione.
+\textit{page fault} causato dal meccanismo di \itindex{copy~on~write}
+\textit{copy on write}. Infatti se nella \index{sezione~critica} sezione
+critica si va ad utilizzare memoria che non è ancora stata riportata in RAM si
+potrebbe avere un \textit{page fault} durante l'esecuzione della stessa, con
+conseguente rallentamento (probabilmente inaccettabile) dei tempi di
+esecuzione.
In genere si ovvia a questa problematica chiamando una funzione che ha
allocato una quantità sufficientemente ampia di \index{variabili!automatiche}
allocazione,\footnote{entrambe queste operazioni causano in genere la
corruzione dei dati di controllo delle funzioni di allocazione, che vengono
anch'essi mantenuti nello \itindex{heap} \textit{heap} per tenere traccia
- delle zone di memoria allocata.} o i classici \itindex{memory~leak}
-\textit{memory leak}.
+ delle zone di memoria allocata.} o i classici \textit{memory leak}.
Abbiamo visto in sez.~\ref{sec:proc_mem_lock} come una prima funzionalità di
ausilio nella ricerca di questi errori sia l'uso della variabile di ambiente
projects / gapil.git / blobdiff