Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Nov 2000 17:30:54 +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:  <200011151730.KAA12666@usr01.primenet.com>
In-Reply-To: <Pine.LNX.4.21.0011141720170.25493-100000@duckman.distro.conectiva> from "Rik van Riel" at Nov 14, 2000 05:21:09 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> > > Thank you!  This gets the me disk %busy, which is one of the things I
> > > was looking for.  Now, can anyone tell me how to tell what percentage of
> > > processor time is being spent waiting for disk I/O to complete?
> > 
> > Uh, none?
> > 
> > If there is disk I/O pending, the processor just runs a
> > different process... am I missing your question?
> 
> 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?  I think you get
what you pay for, when it comes to engineering skill.  It's
easy to write code that stalls, and then expect to be able
to throw clock-doubled hardware at it to "fix it".

I'm always tempted to set up a company where the main
engineers have a centralized batch compile server, so as to
not slow down developement, but requiring that they run no
better than a 386SX/16 on their desktop.  If they are good,
I'd give them a full 8M of real RAM, instead of 4M.

Modern bloat-ware really pisses me off; I built the bind
library the other day: the frigging thing was 4M, unstripped.


					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?200011151730.KAA12666>