Qual è il progresso relativo al miglioramento delle prestazioni / reattività del sistema durante l'I / O su disco elevato?

Ogni volta che c'è un elevato I / O del disco, il sistema tende ad essere molto più lento e meno reattivo del solito. Quali sono i progressi sul kernel Linux riguardo a questo? Questo problema sta lavorando attivamente?

Penso che per la maggior parte sia stato risolto. Le mie prestazioni sotto forte IO sono migliorate in 2.6.36 e mi aspetto che migliorino di più in 2.6.37. Vedi questi articoli phoronix .

Wu Fengguang e KOSAKI Motohiro hanno pubblicato patch questa settimana che ritengono possano risolvere alcuni di questi problemi di reattività, per i quali chiamano il bug "il sistema non risponde alla pressione della memoria e molte pagine sporche / riscrivibili". Andreas Mohr, uno degli utenti che ha segnalato questo problema all'LKML e ha testato le due patch applicate contro il vmscan del kernel ha riportato il successo. Il problema di Andreas era che il sistema non rispondeva completamente (e il passaggio a un VT impiegava più di 20 secondi) quando si creava un file system EXT4 quando un'unità a stato solido era collegata tramite USB 1.1. Sul suo sistema quando scrivevo 300M dal file / dev / zero il problema era ancora peggiore.

Ecco un link diretto al bug

Anche da Phoronix

Fortunatamente, dai nostri test e dai rapporti di altri utenti Linux che cercano di correggere questo problema, le patch vmscan relativamente piccole che sono state pubblicate sembrano affrontare meglio il problema. L'interfaccia utente (GNOME nel nostro caso) non è ancora fluida al 100% se il sistema sta sostenendo una quantità schiacciante di attività del disco, ma è certamente molto meglio di prima e ciò che si trova anche in questo momento con il kernel 2.6.35 di Linux.

C'è anche l' annuncio di rilascio di Phoronix 2.6.36

Sembra che le barriere al blocco stiano scomparendo e ciò dovrebbe anche aiutare le prestazioni.

In pratica, le barriere hanno una reputazione spiacevole per l'uccisione delle prestazioni di I / O dei blocchi, al punto che gli amministratori sono spesso tentati di spegnerli e correre i loro rischi. Mentre le operazioni di coda con tag fornite dall'hardware contemporaneo dovrebbero implementare le barriere ragionevolmente bene, i tentativi di utilizzare tali funzionalità hanno generalmente incontrato difficoltà. Quindi, nel mondo reale, le barriere vengono implementate semplicemente svuotando la coda delle richieste di I / O prima di eseguire l'operazione di barriera, con alcune operazioni di flush avviate per far sì che l'hardware commetta effettivamente i dati su supporti persistenti. Le operazioni di svuotamento della coda bloccheranno il dispositivo e uccideranno il parallelismo necessario per la piena prestazione; non sorprende che l'uso delle barriere possa essere doloroso.

C'è anche questo articolo LWN sulla programmazione I / O corretta

Direi che IO si è risvegliato come un grosso problema circa il tempo del rilascio di ext4 in 2.6.28. I seguenti collegamenti sono alle versioni del kernel per principianti del kernel Linux , è necessario rivedere le sezioni Block e Filesystems. Questo potrebbe ovviamente essere un sentimento ingiusto, o proprio nel momento in cui ho iniziato a guardare lo sviluppo di FS, sono sicuro che stia migliorando da sempre, ma sento che alcuni dei problemi di ext4 "hanno fatto sì che le persone guardassero con attenzione allo stack IO, o potrebbe essere che si aspettassero ext4 per risolvere tutti i problemi di prestazioni, e poi quando non lo hanno realizzato hanno dovuto cercare altrove i problemi.

2.6.28 , 2.6.29 , 2.6.30 , 2.6.31 , 2.6.32 , 2.6.33 , 2.6.34 , 2.6.35 , 2.6.36 , 2.6.37