linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug McNaught <doug@wireboard.com>
To: Mark Swanson <swansma@yahoo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 242-ac3 loop bug
Date: 24 Feb 2001 13:57:36 -0500	[thread overview]
Message-ID: <m3u25jzz6n.fsf@belphigor.mcnaught.org> (raw)
In-Reply-To: <20010224181136.18532.qmail@web1301.mail.yahoo.com>
In-Reply-To: Mark Swanson's message of "Sat, 24 Feb 2001 10:11:36 -0800 (PST)"

Mark Swanson <swansma@yahoo.com> writes:

> --- Doug McNaught <doug@wireboard.com> wrote:
> > It's just an artifact of the fact that processes in state D
> > (uninterruptible sleep) are included in the load average calculation.
> > Since the loop thread apparently sits in state D waiting for events
> > on its device, you get a load average of 1 for each mounted loop
> > device. 
> 
> My thought was that the calculation seems to be misleading. The loop
> process isn't taking up any CPU time. My applications are running
> faster than ever. I'm guessing that ps (and /proc/loadavg) need to make
> the distinction between:
> 1. uninterruptable sleep - where the process is blocking but taking
> 0CPU
> 2. uninterruptable sleep - I/O is happening using CPU
> 
> But I may not understand what uninterruptable sleep is supposed to
> mean.

Well, "sleep" means we're not using CPU at all; we're waiting for
something.  Remember, "load average" isn't purely a CPU measure.

Historically, state D has meant "fast" i/o--reading from disk or tape,
where the result is supposed to be available very soon and it's not
worth doing the extra housekeeping to sleep interruptibly.  Processes
aren't supposed to sit in state D for more than a fraction of a
second.  This being the case, Unix has always factored state D
processes into the load average.  For your distinction to work, there
would have to be an extra flag somewhere saying "I'm in state D, but
don't factor me into the load average", with corresponding code in the
load average calculation routine to honor the flag.  Doable, but not
useful up to now, and only (possibly) worth doing if we get more
threads like the loop driver that sit in D state for a long time. 

This is the first example I've seen in Linux of something sitting in
state D for a long time on purpose.  I agree that IMHO it's not ideal
(for the reason you outline below, mainly).

> Take sendmail for example. Its default configuration for Linux won't
> send attachments if the machine's load is too high. If I have 8 loop
> devices in use and the load is at least 8, this may affect how sendmail
> operates.

Yup. 

The whole Sendmail/load average thing needs careful thought anyway
when setting up a production system--a load average of 8 on an 8-way
system, for example, is a much lighter load than a load of 8 on a
single-CPU machine.

-Doug

  reply	other threads:[~2001-02-24 18:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-24 17:32 242-ac3 loop bug Mark Swanson
2001-02-24 17:59 ` Doug McNaught
2001-02-24 18:11   ` Mark Swanson
2001-02-24 18:57     ` Doug McNaught [this message]
2001-02-24 19:18 ` Arjan van de Ven
2001-02-24 23:14 ` Jens Axboe
2001-02-25  7:48   ` Mircea Ciocan
2001-02-26  0:15 Jonathan Oppenheim
2001-02-26  0:27 ` Jens Axboe
2001-02-26  1:17 ` Mario Hermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3u25jzz6n.fsf@belphigor.mcnaught.org \
    --to=doug@wireboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swansma@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).