[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.069 / U:3.508 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site