SLUG Mailing List Archives
Re: [SLUG] IOWait definition
- To: slug@xxxxxxxxxxx
- Subject: Re: [SLUG] IOWait definition
- From: Daniel Pittman <daniel@xxxxxxxxxxxx>
- Date: Wed, 08 Oct 2008 12:27:57 +1100
- Organization: I know I put it down here, somewhere.
- User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (gnu/linux)
Grant Street <grants@xxxxxxxxx> writes:
> I was wondering if someone could point me in the right direction for
> some doco?
I don't know of any, but ...
> I'm finding it hard to get a definition of what constitutes IOWait.
> I know that IOwait is CPU time waiting for IO to happen to physical local
> disks, but I'm unsure about the following scenarios and if they contribute to
Not quite. IOWait is a *software* state, indicating that a process or
thread is blocked waiting for I/O to complete.
This is different from "CPU time waiting for ..." in that it implies the
software is making no progress, but *NOT* that your CPU is spending
cycles working on it.
> - CPU time waiting for an NFS read/write to occur
Yes, along with more or less any other "disk" I/O that happens to be run
over the network -- as long as it is synchronous, and something is
waiting on it.
> - CPU time waiting for a network buffer to be read/written to. eg waiting for
> a full buffer to clear.
Generally not. I am not certain about blocking on a full buffer
condition for sending data, but not for blocking while reading.
> - Anything else??
Any other synchronous disk I/O, certainly. Probably certain other,
related, conditions where the kernel developers feel that the process is
blocked on I/O.
> PS. How do you set/query the network buffers in Linux?
Via the socket fcntl / ioctl interface, or via the sysctls in
/proc/sys/net, which are documented in the standard Linux kernel sysctl
All that said, you might want to tell us why you are asking, not just
what, since I suspect there is a question about why you have so much
IOWait time on your system, or poor performance?
 It does, technically, spend a few in terms of submitting and
completing the I/O before it wakes up the blocked process, and
various I/O devices need babysitting, but the principal is sound. ;)