lkml.org 
[lkml]   [2001]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: uninteruptable sleep (D state => load_avrg++)
On Wed, 4 Apr 2001, christophe barbe wrote:

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

there may be (and indeed probably are) good technical reasons, however
i am not well enough informed to say what they are.

> Process that will be runnable are not participating to the load so
> why incrementing the load average.

As i understand it:

load avg by nature is a measure of how many processes are 'runnable'
(ie waiting to run) over time.

a process waiting for the kernel to complete IO will indeed be
runnable as soon as the kernel is finished.

instead of waiting for CPU time (as with processes marked R), instead
these processes are waiting for kernel to complete.

> 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.

because the number of processes asleep, waiting on kernel to complete
IO may reasonably be considered to be a load.

imagine a box with a bunch of processes that do almost nothing but
call on the kernel to do IO. If you only count the runnable state
towards load_avg then your load_avg will be very low, even though your
box is swamped - you are ignoring the work of the kernel.

if you count D towards load_avg then it will reflect this abstract
'load' concept more accurately.

Ie, counting D towards load_avg is a way of taking kernel IO work into
account when calculating the load average figures.

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

--paulj

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:23    [from the cache]
©2003-2011 Jasper Spaans