Por que 'sync + drop_caches' não está descartando caches?

Question

Eu tenho um caso de teste para journalctl onde gasta vários segundos lendo do disco . Mas se eu tentar comparar várias execuções do caso de teste, acho que é incrivelmente rápido após a primeira execução. Mesmo se eu tentar deixar caches. Por quê?

$ 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

Curiosamente, time ainda mostra um grande número de pedidos de veiculação por falhas de página ( inputs ). Percebo que, se eu pular o drop_caches entre as execuções, ele mostrará 0.

    

Answer 1

drop_caches afeta apenas o cache do sistema de arquivos do kernel. Isso não afeta os caches no hardware subjacente. Aparentemente, seu hardware tem centenas de megabytes de cache (94992 * 4096 ~ = 400 MB). Impressionante!

No meu caso, é porque o kernel está rodando em uma VM. Portanto, o "hardware subjacente" não é um disco rígido simples. Isso ilustra as configurações de disco usadas por virt-manager .

A opção usada para "modo de armazenamento em cache" respeita os fluxos de gravação (usando fsync() ), mas permite o armazenamento em cache de gravações e leituras no cache de páginas do kernel do host. O "hardware subjacente" inclui efetivamente um cache de disco dentro da RAM do host, potencialmente aumentando para vários gigabytes.

libvirt / KVM chama esse cache de "write-back".

Também percebi que isso acelera a reinicialização da VM.