[lkml]   [2006]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: High load average on disk I/O on 2.6.17-rc3
    Martin Bligh wrote:

    > Nick Piggin wrote:
    >> Perhaps kernel threads in D state should not contribute toward load avg.
    >> Userspace does not care whether there are 2 or 20 pdflush threads
    >> waiting
    >> for IO. However, when the network/disks can no longer keep up, userspace
    >> processes will end up going to sleep in writeback or reclaim --
    >> *that* is
    >> when we start feeling the load.
    > Personally I'd be far happier having separated counters for both.

    Well so long as userspace never blocks, blocked kernel threads aren't a
    bottleneck (OK, perhaps things like nfsd are an exception, but kernel
    threads doing asynch work on behalf of userspace, like pdflush or kswapd).
    It is something simple we can do today that might decouple the kernel
    implementation (eg. of pdflush) from the load average reporting.

    > Then
    > we can see what the real bottleneck is. Whilst we're at it, on a per-cpu
    > and per-elevator-queue basis ;-)

    Might be helpful, yes. At least separate counters for CPU and IO... but
    that doesn't mean the global loadavg is going away.


    Send instant messages to your online friends

    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: 2006-05-09 04:19    [W:0.021 / U:3.272 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site