vmstat: What exactly does cpu wait mean?

Question

today I had a linux system with 100% wait in the vmstat wait Column.

My question here is: What exactly does a processor do when it's waiting for I/O?

To my understanding a cpu can't really wait - it has to run some code! So is it running some tight "wait until the disk interrupt comes" code? Why is it not running other code and returning when the interrupt from the disk arrives?

To my knowledge a disk is soo slow that a cpu can do many, many cycles until the disk is ready.

Why does linux let the cpu wait until the I/O is done instead of giving it some work to do?

Thomas

Answer 1

I've found the answer here: http://veithen.github.io/2013/11/18/iowait-linux.html

So "waiting for I/O" on a processor level means: The Processor is doing nothing than waiting for I/O. While waiting for I/O the Processor can run user code in which case the waiting for I/O disappears and CPU% goes up.

Here the test case from the linked page.

Just run a task which is doing lot of I/O on the first CPU:

taskset 1 dd if=/dev/sda of=/dev/null bs=1MB

You can see that the first CPU is now either running kernel code (sy) or waiting for I/O (wa):

%Cpu0  :  0.0 us,  2.9 sy,  0.0 ni,  0.0 id, 97.1 wa,  0.0 hi,  0.0 si,  0.0 st

Now we start a tight cpu loop on the same cpu:

taskset 1 sh -c "while true; do true; done"

And -look at that- the I/O Wait is gone because the CPU has now some other stuff to do than wait for I/O - it runs userland code!

%Cpu0  : 91.3 us,  1.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  7.3 si,  0.0 st

Hope that helps someone else!

Grettings,

Thomas

Answer 2

IO wait happens if a process is in 'uninterruptible'-states while waiting for the IO-device.

A process is 'uninterruptible' if it currently executes certain system-calls -- a normal read waiting for a disc to spin up won't lead to IO-wait I think -- that would lead to buggy behaviour in the application or possible data-loss if the process were to be interrupted (due to e.g. limitations in the driver used to access special hardware).

Further reading is available after searching the web for e.g. 'linux uninterruptible kernel sleep explained'