19

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.

Right?

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.

chaos
  • 1,445
  • 1
  • 14
  • 21
HUA Di
  • 293
  • 2
  • 5

2 Answers2

23

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.

chaos
  • 1,445
  • 1
  • 14
  • 21
  • 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
  • OH! __THE FALSE PART:__ Just because a CPU is in iowait state does not mean that it can't run other threads or processes on that CPU. <-- the kernel CANNOT issue any more work, that (thing that does instructions - eg core) is totally waiting for something AND CANNOT DO ANYTHING ELSE - also it wont be able to do much cache wise so even the core itself is stuck, this is a proper stall, not just a pipeline stall. – Alec Teal Apr 21 '15 at 19:36
  • 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
  • @AlecTeal Sorry, but that not true. The ther kernel CAN run other processes while in iowait. Or is your operating system always freezing when a process waits for I/O? – chaos Apr 21 '15 at 19:44
  • Are you seriously saying that the CPU spends time waiting for an interrupt from a network controller? If I read from a network I send some crap through a network controller and carry on until it I get an interrupt saying it has data. – Alec Teal Apr 21 '15 at 19:45
  • @chaos there is a time out (see watch-dog timer) – Alec Teal Apr 21 '15 at 19:46
  • @AlecTeal: CPU activity is not the issue. If during a timeslice, no process is runnable but some process is blocked on I/O, the kernel counts that timeslice as "iowait" even though the CPU is idle. It's a kernel accounting behavior, nothing to do with hardware. Again, you can confirm this by simple experiment. – David Apr 21 '15 at 19:48
  • It is not a processes' fault if it misses a turn due to waiting @David however often you can account reading time. This is why timing stuff (you'll see a real and an actual) gives 2 times. However you would not limit a process to real time, but instead CPU time - if you have a DMA controller of course (because then there's ~0 time the CPU is actually waiting for stuff) – Alec Teal Apr 21 '15 at 20:03
  • @David in ye-olden days MAYBE one would count that time because the CPU can literally do nothing else (up to timeouts, you get the idea) while it waited. DMA controllers are not new, and back when CPUs were actually a bunch of daughterboards and a backplane, seeing what we'd now call a DMA controller wasn't rare. You cannot be so young that you've never had a computer freeze for a noticeable amount of a second while trying to read from a dirty floppy. (Wow 1995 was 20 years ago :/ ) – Alec Teal Apr 21 '15 at 20:07
  • @AlecTeal: I'm not able to figure out what relevance that has to this discussion. You claimed that "iowait" time is "The time the kernel has spent inside a low level device I/O routine". How do you explain the fact that a process blocked on a network FS, with no data transfer occurring, is counted as iowait time? Do you refuse to accept that this is true? Have you tried it? – David Apr 21 '15 at 20:11
  • Read it again, fresh eyes FTW – Alec Teal Apr 21 '15 at 20:13
  • DMA is not relevant. Interrupts are not relevant. You made a specific claim that time blocked on NFS reads is not counted as iowait, when it's clear you have not bothered to try the very simple experiment that would disprove it. – David Apr 21 '15 at 20:17
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/23060/discussion-between-david-and-alec-teal). – David Apr 21 '15 at 20:17
  • 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 02:26
-2

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

Community
  • 1
Mike Fiedler
  • 2,152
  • 1
  • 17
  • 33
  • 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. – Roland Pihlakas 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? – Roland Pihlakas 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
  • @EEAA I started to feel that extra downvotes are because the answer uses humble wording. It sounds unsure. Perhaps people start to play out some personal scenario triggered from that situation. People sometimes tend to play out scenarios, even when it's undesirable or even when it's trigger matches inadequately. Stanford prison experiment comes to my mind, but I have seen the phenomenon more often, that experiment is just very extreme example. If so - one is suggested to avoid putting oneself in such scenariolike situations. Though playing out scenarios (if thats true) is still not acceptable. – Roland Pihlakas Apr 21 '15 at 23:31
  • @EEAA Thanks for your first comment. In the event that a question has already been asked and answered on either SF or SO (or any other SE site), is it not better to link to that knowledge, instead of copy&pasting content from others' answers? That way, if the original answer is updated for accuracy, the link will lead others to the correct answer, instead of leaving stale answers here. – Mike Fiedler Apr 22 '15 at 11:06