Re: High load average on disk I/O on 2.6.17-rc3

[Nick Piggin <nickpiggin@yahoo.com.au>]

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 http://au.messenger.yahoo.com