All of lore.kernel.org
 help / color / mirror / Atom feed
From: christophe barbe <christophe.barbe@lineo.fr>
To: Paul Jakma <paulj@itg.ie>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: uninteruptable sleep (D state => load_avrg++)
Date: Wed, 4 Apr 2001 16:48:58 +0200	[thread overview]
Message-ID: <20010404164858.A14009@pc8.inup.com> (raw)
In-Reply-To: <20010404141349.A6702@pc8.inup.com> <Pine.LNX.4.33.0104041518300.1150-100000@rossi.itg.ie>
In-Reply-To: <Pine.LNX.4.33.0104041518300.1150-100000@rossi.itg.ie>; from paulj@itg.ie on mer, avr 04, 2001 at 16:20:04 +0200

<skip>
I've unfortunately no significant Unix culture. 
I'm certainly young enough to be excused and by luck Linux shows me the road to the hacker heaven.
So now I move forward the good direction, trying to understand the POSIX stuff ....
</skip>

>From me, a POV without technical reasons is not a philosical one but more certainly an historical one.

Process that will be runnable are not participating to the load so why incrementing the load average.
Moreover if a process should be in state D only for a short time, the influence of the incrementation should be near null for an AVERAGE value.
So why doing that (I mean load++) if there's an influence only when a process stay in a D state for a long time (= when the only effect is to distort the load measure) ?

What's the technical reason behind this load_avrg++ ???

Christophe


On mer, 04 avr 2001 16:20:04 Paul Jakma wrote:
> On Wed, 4 Apr 2001, 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 ?
> 
> from a philosical POV: they are processes that will be runnable as
> soon as the kernel returns to them.
> 
> no idea if there are technical reasons for it.
> 
> >
> > Thanks,
> > Christophe
> 
> --paulj
> 
-- 
Christophe Barbé
Software Engineer
Lineo High Availability Group
42-46, rue Médéric
92110 Clichy - France
phone (33).1.41.40.02.12
fax (33).1.41.40.02.01
www.lineo.com

  reply	other threads:[~2001-04-04 14:45 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 [this message]
2001-04-04 15:05           ` Paul Jakma
2001-04-04 15:15             ` christophe barbe
2001-04-04 22:39       ` Tim Wright
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=20010404164858.A14009@pc8.inup.com \
    --to=christophe.barbe@lineo.fr \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulj@itg.ie \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.