Page-cache memorizza nella cache le pagine a cui si accede di recente dal disco rigido, riducendo così i tempi di ricerca per gli accessi successivi agli stessi dati. La page-cache non migliora le prestazioni al primo accesso a una pagina dal disco rigido. Quindi, se un'app ha intenzione di leggere un file una sola volta, bypassare la page-cache è il modo migliore per procedere. Ciò è possibile utilizzando il flag O_DIRECT. Ciò significa che il kernel non considera questi particolari dati per la page-cache. Ridurre la contesa della cache significa che le altre pagine (a cui si accederebbe ripetutamente) hanno maggiori possibilità di essere conservate nella cache della pagina. In questo modo viene migliorata la percentuale di riscontri nella cache, con prestazioni migliori.
void ioReadOnceFile()
{
/* L'utilizzo di direct_fd e direct_f ignora la cache della pagina del kernel.
* - direct_fd è un descrittore
di file di basso livello* - direct_f è un filestream simile a quello restituito da fopen()
* NOTA: Utilizzare getpagesize() per determinare i buffer di dimensioni ottimali.
*/
int direct_fd = open("nome file", O_DIRECT | O_RDWR);
FILE *direct_f = fdopen(direct_fd, "w+");
/* I/O diretto del disco fatto QUI*/
fclose(f);
close(fd);
}
Si consideri il caso di una lettura in un file di grandi dimensioni (cioè un database) composto da un numero enorme di pagine. Ogni pagina successiva a cui si accede va nella cache della pagina solo per essere abbandonata in seguito man mano che vengono lette sempre più pagine. In questo modo si riduce notevolmente la percentuale di riscontri nella cache. In questo caso, page-cache non fornisce alcun miglioramento delle prestazioni. Quindi sarebbe meglio bypassare la page-cache quando si accede a file di grandi dimensioni.
void ioLargeFile()
{
/* L'utilizzo di direct_fd e direct_f bypassa la page-cache del kernel.
* - direct_fd è un descrittore
di file di basso livello* - direct_f è un filestream simile a quello restituito da fopen()
* NOTA: Utilizzare getpagesize() per determinare i buffer di dimensioni ottimali.
*/
int direct_fd = open("largefile.bin", O_DIRECT | O_RDWR | O_LARGEFILE);
FILE *direct_f = fdopen(direct_fd, "w+");
/* I/O diretto del disco fatto QUI*/
fclose(f);
close(fd);
}
L'io-scheduler ottimizza l'ordine delle operazioni di I/O da aggiungere al disco rigido. Poiché il tempo di ricerca è la penalità più pesante su un disco rigido, la maggior parte degli scheduler di I/O tenta di ridurre al minimo il tempo di ricerca. Questo viene implementato come una variante dell'algoritmo dell'elevatore, cioè riordinare le richieste ordinate casualmente da numerosi processi nell'ordine in cui i dati sono presenti sul disco rigido, richiede una notevole quantità di tempo di CPU.
Alcune attività che comportano operazioni complesse tendono a essere limitate dalla velocità con cui la CPU è in grado di elaborare grandi quantità di dati. Un complesso I/O scheduler in esecuzione in background può consumare preziosi cicli della CPU, riducendo così le prestazioni del sistema. In questo caso, il passaggio a un algoritmo più semplice come no-op riduce il carico della CPU e può migliorare le prestazioni del sistema.
echo noop > /sys/block//queue/scheduler
Anche se questo alla fine porterà a termine il lavoro, non è sicuramente il modo più ottimale. Dal punto di vista del kernel, la dimensione ottimale per le richieste di I/O è la dimensione del blocco del file system (cioè la dimensione della pagina). Poiché tutto l'I/O nel file system (e nella cache della pagina del kernel) è in termini di pagine, ha senso che l'app esegua trasferimenti anche in multipli di dimensioni della pagina. Inoltre, con le cache multi-segmentate che si stanno facendo strada nei dischi rigidi, si trarrebbe un enorme vantaggio dall'esecuzione di I/O in multipli della dimensione del blocco.
Il seguente comando può essere usato per determinare la statistica ottimale della dimensione
del blocco--printf="bs=%s optimal-bs=%S\n" --file-system /dev/
Quando un'app avvia una lettura di I/O SYNC, il kernel accoda un'operazione di lettura per i dati e restituisce un valore solo dopo la rilettura dell'intero blocco di dati richiesti. Durante questo periodo, il kernel contrassegnerà il processo dell'applicazione come bloccato per l'I/O. Altri processi possono utilizzare la CPU, con conseguenti prestazioni complessivamente migliori per il sistema.
Quando un'app avvia una scrittura di I/O SYNC, il kernel mette in coda un'operazione di scrittura per i dati che inseriscono il processo dell'applicazione in un I/O bloccato. Sfortunatamente, ciò significa che il processo dell'applicazione corrente è bloccato e non può eseguire altre elaborazioni (o I/O, se è per questo) fino al completamento di questa operazione di scrittura.
Quando un'app avvia una lettura di I/O asincrona, la funzione read() in genere restituisce un valore aggiunto dopo aver letto un sottoinsieme del blocco di dati di grandi dimensioni. L'app deve chiamare ripetutamente read() con le dimensioni dei dati rimanenti da leggere, fino a quando non vengono letti tutti i dati necessari. Ogni chiamata aggiuntiva alla lettura introduce un certo sovraccarico in quanto introduce un cambio di contesto tra lo spazio utente e il kernel. L'implementazione di un ciclo stretto per chiamare ripetutamente read() spreca cicli di CPU che altri processi avrebbero potuto utilizzare. Quindi di solito si implementa il blocco usando select() fino a quando il successivo read() restituisce un read-in diverso da zero. cioè l'ASYNC è fatto per bloccarsi proprio come fa la lettura SYNC.
Quando un'app avvia una scrittura di I/O asincrona, il kernel aggiorna le pagine corrispondenti nella cache di pagina e le contrassegna come sporche. Quindi il controllo torna rapidamente all'app che può continuare a funzionare. I dati vengono scaricati sul disco rigido in un secondo momento ottimale (basso carico della CPU) in un modo più ottimale (scritture raggruppate in sequenza).
Pertanto, le letture SYNC e le scritture ASYNC sono generalmente un buon modo per procedere, in quanto consentono al kernel di ottimizzare l'ordine e la tempistica delle richieste di I/O sottostanti.