Ho un test case per journalctl dove trascorre diversi secondi a leggere dal disco. Ma se provo a confrontare più esecuzioni del test case, scopro che è incredibilmente veloce dopo la prima esecuzione. Anche se provo a eliminare le cache. Perché?
$ sync && echo 1 | sudo tee /proc/sys/vm/drop_caches && /usr/bin/time journalctl -b -u dev-shm.mount
1
0.01user 0.03system 0:04.50elapsed 1%CPU (0avgtext+0avgdata 30956maxresident)k
95424inputs+0outputs (424major+665minor)pagefaults 0swaps
$ sync && echo 1 | sudo tee /proc/sys/vm/drop_caches && /usr/bin/time journalctl -b -u dev-shm.mount >/dev/null
1
0.00user 0.01system 0:00.08elapsed 26%CPU (0avgtext+0avgdata 31832maxresident)k
94992inputs+0outputs (422major+445minor)pagefaults 0swaps
Interessante time mostra ancora che esegue molti I/O a causa di errori di pagina (inputs ). Noto che se salto il drop_caches tra le corse, mostra invece 0.
Risposta accettata:
drop_caches influisce solo sulla cache del filesystem del kernel. Non influisce sulle cache nell'hardware sottostante. Apparentemente il tuo hardware ha centinaia di megabyte di cache (94992 * 4096 ~=400 MB). Fantastico!
Nel mio caso, è perché il kernel è in esecuzione in una macchina virtuale. Quindi "l'hardware sottostante" non è un semplice disco rigido. Questo illustra le impostazioni del disco utilizzate da virt-manager .
L'opzione utilizzata per la "modalità cache" rispetta i flush di scrittura (usando fsync() ), ma per il resto consente di memorizzare nella cache sia le scritture che le letture nella cache della pagina del kernel host. L '"hardware sottostante" include effettivamente una cache del disco all'interno della RAM dell'host, potenzialmente in crescita fino a più gigabyte.
libvirt / KVM chiama questa cache "writeback".
Ho anche notato che questo accelera il riavvio della VM.