Date: Thu, 16 Nov 2000 08:28:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: riel@conectiva.com.br (Rik van Riel) Cc: tlambert@primenet.com (Terry Lambert), float@firedrake.org (void), hackers@FreeBSD.ORG Subject: Re: "iowait" CPU state Message-ID: <200011160828.BAA00995@usr02.primenet.com> In-Reply-To: <Pine.LNX.4.21.0011151704110.5584-100000@duckman.distro.conectiva> from "Rik van Riel" at Nov 15, 2000 05:07:02 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I guess it might be useful to see the difference between > > > "true" idle time and time the system couldn't do anything > > > useful because it was blocked on the disk (but /should/ > > > have done something useful...). > > > > You mean because the programmer didn't interleave their I/O, > > and wrote to a threads interface, or some other interface > > that's prone to subsystem stalling, instead? > > Interleaving IO only makes sense when you have tons of > parallelisable jobs. If you have one big serial job this > doesn't buy you anything... Then neither does looking at how it's not running. 8-). > Yes, you can use a separate thread to queue IO in > advance, but in this case it might just be useful to > have the %iowait statistic so you know how much work > to queue in advance. These statistics are only available to priviledged programs and/or programs willing to popen() priviledged programs. > Then again, this may be a bad example. I can't quite > put my finger on it, but somehow I have the idea that > the %iowait may be a useful statistic to keep... It's not there now. > > Modern bloat-ware really pisses me off; I built the bind > > library the other day: the frigging thing was 4M, unstripped. > > How does this affect the (non?-)usefullness of the > %iowait statistic? When you are waiting for I/O in a well written program, it is because there's nothing left to do but wait, which would make the statistic useless. If there's something else you could do, and you're waiting, by definition the program is not well written (well written programs don't waste time for no good reason). In a badly written program, I guess you could argue that a manager could use it to decide who didn't think before they wrote their code, for things like proportioning merit raises or pink slips, based on whether or not someone thought before they wrote their code... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011160828.BAA00995>