[lkml]   [2001]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 242-ac3 loop bug
    Mark Swanson <> writes:

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


    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:17    [W:0.023 / U:12.660 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site