¿Iowait incluye tiempo de espera para llamadas de red?

La página de proc(5)manual describe iowait como "tiempo de espera para que IO se complete". Esto se explicó principalmente en una pregunta anterior. Mi pregunta es: mientras espero bloquear IO, ¿esto incluye esperar al bloquear IO de red o solo IO local?

Significa esperar "E / S de archivo", es decir, cualquier llamada de lectura / escritura en un archivo que está en el sistema de archivos montado, pero también probablemente cuenta el tiempo de espera para intercambiar o cargar páginas en la memoria, por ejemplo, bibliotecas no en memoria todavía, o páginas de archivos mmap () 'd que no están en ram.

NO cuenta el tiempo dedicado a esperar objetos IPC como enchufes, tuberías, ttys, select (), poll (), sleep (), pause () etc.

Básicamente, es hora de que un hilo pase esperando disco-IO síncrono; durante este tiempo es teóricamente capaz de ejecutarse pero no puede porque algunos datos que necesita aún no están allí. Tales procesos generalmente aparecen en estado "D" y contribuyen al promedio de carga de una caja.

Confusamente, creo que esto probablemente incluye el archivo IO en los sistemas de archivos de red.

El tiempo de espera es la cantidad de tiempo que un proceso pasa en el planificador de E / S del núcleo. Hasta donde yo sé, esto no tiene nada que ver con las E / S de red en la medida en que las conexiones de socket regulares van. Sin embargo, incluirá el tiempo dedicado a esperar sistemas de archivos de red como NFS.

Lo hace.

Por cierto, uno de los servidores que administro está experimentando un alto iowait que es causado por un mal montaje NFS.

top - 06:19:03 up 14 days, 10:15,  3 users,  load average: 9.67, 11.83, 12.31
Tasks: 135 total,   1 running, 134 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.2%sy,  0.0%ni,  0.0%id, 99.7%wa,  0.0%hi,  0.0%si,  0.0%st

top - 06:22:55 up 14 days, 10:19,  3 users,  load average: 10.58, 11.13, 11.89
Tasks: 137 total,   1 running, 136 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.2%sy,  0.0%ni,  0.0%id, 99.8%wa,  0.0%hi,  0.0%si,  0.0%st

Y mira los procesos en el Destado.

root     27011  0.0  0.0      0     0 ?        S    03:12   0:00 [nfsd4]
root     27012  0.0  0.0      0     0 ?        S    03:12   0:00 [nfsd4_callbacks]
root     27013  0.0  0.0      0     0 ?        D    03:12   0:01 [nfsd]
root     27014  0.0  0.0      0     0 ?        D    03:12   0:01 [nfsd]
root     27015  0.0  0.0      0     0 ?        D    03:12   0:01 [nfsd]
root     27016  0.0  0.0      0     0 ?        D    03:12   0:01 [nfsd]

El iowait incluye las llamadas de red. Digo esto, porque NFS se maneja como muchos sistemas de archivos locales de Linux desde el punto de vista del núcleo:

$ vim linux-2.6.38.2/fs/nfs/file.c 

const struct file_operations nfs_file_operations = {
        .llseek         = nfs_file_llseek,
        .read           = do_sync_read,
        .write          = do_sync_write,
        .aio_read       = nfs_file_read,
        .aio_write      = nfs_file_write,
        .mmap           = nfs_file_mmap,
        .open           = nfs_file_open,
        .flush          = nfs_file_flush,
        .release        = nfs_file_release,
        .fsync          = nfs_file_fsync,
        .lock           = nfs_lock,
        .flock          = nfs_flock,
        .splice_read    = nfs_file_splice_read,
        .splice_write   = nfs_file_splice_write,
        .check_flags    = nfs_check_flags,
        .setlease       = nfs_setlease,
};

Cuando los procesos llaman a escribir en el descriptor de archivo 5, sucederá algo como esto:

files->fd_array[5]->f_op->write(argv.......)

Entonces, el proceso no sabe qué tipo de sistema de archivos está usando (vfs magic) y el iowait es el mismo para un sistema de archivos local.