I know wa (in top) measures the CPU time on waiting for I/O. Many articles say that.

But I am confused that, based on 2 knowledge points:

  1. if a process uses a system call to read disk, the process is blocked.
  2. If a process is blocked, it is cannot be scheduled running on CPU.


It seems there no time for CPU waiting on I/O... What happens?

If recommend some books or articles for me to further reading, so much the better.

  • I stepped in and wrote a proper answer. Sorry I wasn't there when you needed me ;-)
    – Alec Teal
    Apr 21 '15 at 19:34

The CPU idle status is divided in two different "sub"-states: iowait and idle.

If the CPU is idle, the kernel then determines if there is at least one I/O currently in progress to either a local disk or a remotely mounted disk (NFS) which had been initiated from that CPU. If there is, then the CPU is in state iowait. If there is no I/O in progress that was initiated from that CPU, the CPU is in idle state.

So, iowait is the percentage of time the CPU is idle AND there is at least one I/O in progress initiated from that CPU.

The iowait counter states that the system can handle more computational work. Just because a CPU is in iowait state does not mean that it can't run other threads or processes on that CPU.

So, iowait is simply a form of idle time.

  • This is actually false. Also NFS - the CPU doesn't even have a concept of that. It is basically the time the CPU has spent unable to do something else because it is dealing with some low-level IO stuff - in the sense of accessing something connected to it NOT process I/O which is usually reading files and whatnot. For example on the Raspberry Pi there is no DMA controller, so the CPU cannot go "hey Motherboard read me this many bytes starting here from the card and put them in ram starting here" it must do it manually->
    – Alec Teal
    Apr 21 '15 at 19:02
  • so it spends A LOT of time CONSTANTLY waiting for io as in for a card read to complete. You make it sound like a cache miss could be measured by this "io wait" (which of course is not counted), IO wait is defined as follows: The time the kernel has spent inside a low level device I/O routine - eg the RPi, it literally has to do the reading procedure from the card and the CPU (being a DMA-less chump) has to wait for data on the IO bus. With a DMA controller, it speaks to the controller and says "tell me when you're done" - leaving it to do other stuff while the DMA controller does device IO
    – Alec Teal
    Apr 21 '15 at 19:06
  • Use dstat to see IOwaiting BTW, also iowait and time spent doing kernel stuff can't really be measured per-process. Like say there are two processes "writing" to "files", the first one completes quickly, the FS chose to cache writes for whatever reason, the second one causes the cache to flush, it's not fair to count the much longer time to return from write to the process that caused the write. Same with I/O wait, which is why they're not per-process measured.
    – Alec Teal
    Apr 21 '15 at 19:14
  • 4
    @AlecTeal: No, it is correct and your comments are false. iowait counts time blocked on I/O, not servicing I/O. If you don't want to confirm this by reading the kernel source, try an experiment: mount a network filesystem, start reading a file, and then firewall off the remote machine. iowait time will still be high even though the processor is completely idle.
    – David
    Apr 21 '15 at 19:43
  • 1
    I did a test on this answer. dd if=/dev/sda of=/dev/null to make a high wa. Then run a while-true code, wa is instead of us. Thanks chaos.
    – HUA Di
    Apr 27 '15 at 2:26

I'm not 100% sure I understand the question, but there's some ideas.

There's another question here that asked this, and has some good answers: Can anyone explain precisely what IOWait is?

There's a good post here: http://veithen.github.io/2013/11/18/iowait-linux.html

  • 7
    Mike, it's preferred that answers include content, not just links to content. By providing content here, you're ensuring that your answer still has value when those links go away.
    – EEAA
    Apr 21 '15 at 15:05
  • 1
    @EEAA then the answer needs to be edited, not triply downvoted? Or it can be moved into a comment. It still contains useful information. Downvotes mean kind of that the info is useless, also by making it almost invisible? I am not saying that you did downvote, I am just wondering about the approach people have here. Apr 21 '15 at 22:42
  • 3
    @RolandPihlakas It's a matter of motivation. Downvote+comment in this situation give motivation for the user to fix their answer. I'll gladly remove my dv after the answer is fixed. Editing these are counter-productive, as it enables bad behavior. We've had several users through the years that have only ever posted link-only answers, in spite of being asked not to do so. If users can't bother to put in a bit of effort into their answers, I'm not going to help them out by fixing their work.
    – EEAA
    Apr 21 '15 at 22:53
  • @EEAA Thanks for the elaborate answer. Your approach is understandable and through Your comments You deliver the motivational nudge for the answer's author too. In contrast, I am afraid silent downvotes mostly do not deliver any practical motivation since they are obscure. But I was a bit imprecise - I was wondering mostly why was the answer downvoted so much that it got greyed out? Your comment with the one or two downvotes should have sufficed? Apr 21 '15 at 23:00
  • 2
    @RolandPihlakas People thought the answer wasn't useful, so they downvoted. They downvoted because it's Tuesday. They downvoted because it's snowing in Minneapolis today (really, it is, and it shouldn't be this late in the spring). Who knows.
    – EEAA
    Apr 21 '15 at 23:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.