Há uma sugestão em uma leitura atenta de man iotop
At least the CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING, CONFIG_TASKSTATS and CONFIG_VM_EVENT_COUNTERS options need to be enabled in your Linux kernel build configuration.
iotop displays columns for the I/O bandwidth read and written by each process/thread during the sampling period. It also displays the per‐ centage of time the thread/process spent while swapping in and while waiting on I/O. For each process, its I/O priority (class/level) is shown.
In addition, the total I/O bandwidth read and written during the sampling period is displayed at the top of the interface. Total DISK READ and Total DISK WRITE values represent total read and write bandwidth between processes and kernel threads on the one side and kernel block device subsystem on the other. While Actual DISK READ and Actual DISK WRITE values represent corresponding bandwidths for actual disk I/O between kernel block device subsystem and underlying hardware (HDD, SSD, etc.). Thus Total and Actual values may not be equal at any given moment of time due to data caching and I/O operations reordering that take place inside Linux kernel.
CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING, CONFIG_TASKSTATS são semelhantes às estatísticas por tarefa que compõem Total . Considerando CONFIG_VM_EVENT_COUNTERS é uma estatística global única, ou seja, Actual (em /proc/vmstat , se você procurar a opção de configuração). A parte da VM, que significa Memória Virtual, sugere strongmente que isso é sobre o IO do kernel com buffer, ou seja, o que passa pelo cache da página. Em outras palavras, essas estatísticas estão sendo capturadas à medida que o IO passa do subsistema da VM para o subsistema de dispositivo de bloco.
Ele sugere que o IO, que ignora a VM, não será contado em iotop . É provável que não inclua O_DIRECT , por exemplo. Isso também explica como iotop evita qualquer contagem dupla de IO passada por meio de software RAID (e LVM, etc.) e por que não possui recursos para dividir estatísticas para diferentes dispositivos de bloco.
O IO ressincronizado por RAID não precisa passar pelo cache da página. Ele estará usando APIs no kernel, que eu acho que compartilham algumas semelhanças com o IO async (o Linux suporta apenas O_DIRECT para IOs assíncrono). Portanto, ele não sofre a limitação de desempenho de usar read() e write() sem o write-back assíncrono e o readahead fornecidos pelo cache de páginas.