public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tim Wright <timw@splhi.com>
To: christophe barbe <christophe.barbe@lineo.fr>
Cc: linux-kernel@vger.kernel.org
Subject: Re: uninteruptable sleep (D state => load_avrg++)
Date: Wed, 4 Apr 2001 15:39:23 -0700	[thread overview]
Message-ID: <20010404153923.B2144@kochanski> (raw)
In-Reply-To: <20010404094708.A4718@pc8.inup.com> <E14klGU-0001kB-00@the-village.bc.nu> <20010404141349.A6702@pc8.inup.com>
In-Reply-To: <20010404141349.A6702@pc8.inup.com>; from christophe.barbe@lineo.fr on Wed, Apr 04, 2001 at 02:13:49PM +0200

On Wed, Apr 04, 2001 at 02:13:49PM +0200, christophe barbe wrote:
> The sleep should certainly be interruptible and I that's what I said to the GFS guy.
> But what the reason to increment the load average for each D process ?
> 

OK, the Unix history goes something like this. Synchronization was achieved
using two primitives, sleep() and wakeup(). These guys rendezvous'd on a
wait channel, which was simply an 'int', and by convention was actually the
address of a data structure (yes I know int and pointers aren't the same, this
is a long time ago, OK ? :-).
Anyway, when you called sleep, you also had an associated priority. Priority
values less than PZERO were "high" priority, and >= PZERO were "low" priority.
sleeping above PZERO was interruptible, and processes sleeping at this priority
did not count towards the load. The idea was to use this for events that
potentially might never happen. Sleeping at a priority < PZERO was intended
to be used for things that are absolutely 100% guaranteed to happen, preferably
sometime very soon. Disk I/O (real disks, not NFS) fell into this category,
and hence it counts towards the load since this could be deemed a "fast wait"
state, and the process is nominally runnable. All a bit hand-wavy I know, but
it worked well enough.

The really important part of all this is that you should never sleep
uninterruptibly for anything that you cannot absolutely guarantee will happen,
otherwise you wind up with a stuck process.

Regards,

Tim


-- 
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI

  parent reply	other threads:[~2001-04-04 22:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-03 16:40 uninteruptable sleep Manfred Spraul
2001-04-04  7:47 ` uninteruptable sleep (D state => load_avrg++) christophe barbe
2001-04-04 11:15   ` Alan Cox
2001-04-04 12:13     ` christophe barbe
2001-04-04 12:53       ` Alan Cox
2001-04-04 14:20       ` Paul Jakma
2001-04-04 14:48         ` christophe barbe
2001-04-04 15:05           ` Paul Jakma
2001-04-04 15:15             ` christophe barbe
2001-04-04 22:39       ` Tim Wright [this message]
2001-04-04 16:07 ` uninteruptable sleep christophe barbe

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=20010404153923.B2144@kochanski \
    --to=timw@splhi.com \
    --cc=christophe.barbe@lineo.fr \
    --cc=linux-kernel@vger.kernel.org \
    /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