performance -> prestazioni piu' una nota sulle large pages

diff --git a/process.tex b/process.tex
index 831c6482e8e4b096847d7bf8a392d1b9225cba85..0678e277a3882de71aec3782dddb610eb7f0e72f 100644 (file)
--- a/process.tex
+++ b/process.tex
@@ -276,10 +276,13 @@ necessariamente adiacenti).
 Per la gestione da parte del kernel la memoria virtuale viene divisa in pagine
 di dimensione fissa (che ad esempio sono di 4kb su macchine a 32 bit e 8kb
 sulle alpha, valori strettamente connessi all'hardware di gestione della
-memoria), e ciascuna pagina della memoria virtuale è associata ad un supporto
-che può essere una pagina di memoria reale o ad un dispositivo di stoccaggio
-secondario (in genere lo spazio disco riservato alla swap, o i file che
-contengono il codice).
+memoria),\footnote{con le versioni più recenti del kernel è possibile anche
+  utilizzare pagine di dimensioni maggiori, per sistemi con grandi
+  quantitativi di memoria in cui l'uso di pagine troppo piccole comporta una
+  perdita di prestazioni.} e ciascuna pagina della memoria virtuale è
+associata ad un supporto che può essere una pagina di memoria reale o ad un
+dispositivo di stoccaggio secondario (in genere lo spazio disco riservato alla
+swap, o i file che contengono il codice).
 
 Lo stesso pezzo di memoria reale (o di spazio disco) può fare da supporto a
 diverse pagine di memoria virtuale appartenenti a processi diversi (come
@@ -568,7 +571,7 @@ che contiene l'errore. Per questo motivo 
 In C e C++ il problema è particolarmente sentito. In C++, per mezzo della
 programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente
 ridimensionato attraverso l'uso accurato di appositi oggetti come gli
-\textit{smartpointers}.  Questo però va a scapito delle performance
+\textit{smartpointers}.  Questo però va a scapito delle prestazioni
 dell'applicazione in esecuzione.
 
 In altri linguaggi come il java e recentemente il C\# il problema non si pone
@@ -581,11 +584,11 @@ In tal caso, attraverso meccanismi simili a quelli del \textit{reference
 riferita da nessuna parte del codice in esecuzione, può essere deallocata
 automaticamente in qualunque momento dall'infrastruttura.
 
-Anche questo va a scapito delle performance dell'applicazione in esecuzione
+Anche questo va a scapito delle prestazioni dell'applicazione in esecuzione
 (inoltre le applicazioni sviluppate con tali linguaggi di solito non sono
 eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria
 la presenza di una infrastruttura per la loro interpretazione e pertanto hanno
-di per sé delle performance più scadenti rispetto alle stesse applicazioni
+di per sé delle prestazioni più scadenti rispetto alle stesse applicazioni
 compilate direttamente).  Questo comporta però il problema della non
 predicibilità del momento in cui viene deallocata la memoria precedentemente
 allocata da un oggetto.