From: James Pearson <james-p@moving-picture.com>
To: linux-kernel@vger.kernel.org
Subject: Re: High load average on idle machine running 2.6.32
Date: Mon, 14 Dec 2009 17:49:16 +0000 [thread overview]
Message-ID: <4B267A9C.6010804@moving-picture.com> (raw)
In-Reply-To: <4B2121E2.2030900@moving-picture.com>
James Pearson wrote:
>> I've booted a 64 bit 2.6.32 kernel on dual processor, quad core Xeon
>> E5440 machine. The load average when the machine is idle varies
>> between 2 and 3.
>>
>> When using a 2.6.31 kernel on the same machine, the load average when
>> idle is nearly 0
>>
>> The kernel doesn't use modules - all that is needed is compiled in.
>> The machine uses NFS-root
>>
>> Strangely, when I run 'iftop' (from
>> http://www.ex-parrot.com/pdw/iftop/) using the 2.6.32 kernel, the load
>> average drops to below 0.5 - stop running iftop, and the load average
>> climbs again ...
>>
>> Any idea what might be causing this?
>
>
> It looks like whatever is causing this happened between 2.6.31-git7 and
> 2.6.31-git8 - unfortunately I don't know how to find out what change
> caused this ...
>
> Also, if I 'hot-unplug' CPUs 1 to 7, the load average drops to 0 - when
> I re-enable theses CPUs, the load average climbs.
>
> I guess this is a problem with my particular config - or maybe because
> I'm using NFS-root (the root file system is readonly), or using a
> non-module kernel?
I gave 'git bisect' a go - which appears to suggest that my problem
started at:
% git bisect bad
d7c33c4930f569caf6b2ece597432853c4151a45 is first bad commit
commit d7c33c4930f569caf6b2ece597432853c4151a45
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Fri Sep 11 12:45:38 2009 +0200
sched: Fix task affinity for select_task_rq_fair
While merging select_task_rq_fair() and sched_balance_self() I made
a mistake that leads to testing the wrong task affinty.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
:040000 040000 3d7aa3e193c7faf9c7ebbb1443c6f63269d86d04
9cfb647eb5d80f156fd8a495da68f765c3fdd772 M kernel
However, while running the bisects, it became harder to decide what was
a 'bad' and a 'good' idle load average - for example the kernel with the
above patch gave an idle load average of about 1.5 - which is not as
high as the idle load average seen with a 2.6.32 kernel and the kernel
without this patch gave an idle load average of about 0.7 - which is not
as low as the idle load average with a 2.6.31 kernel ...
So I guess, it is not just one patch that has caused the issue I'm
seeing, which I guess is to be expected as the above patch was part of
the 'scheduler updates for v2.6.32' patch set
<http://marc.info/?l=linux-kernel&m=125322428306777&w=2>
I guess as no one else has reported this issue - it must be something to
do with my set up - could using NFS-root affect how the load average is
calculated?
Or, do I have something strange or missing in my kernel config that
could cause this issue?
Thanks
James Pearson
next prev parent reply other threads:[~2009-12-14 17:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-07 23:14 High load average on idle machine running 2.6.32 James Pearson
2009-12-10 16:29 ` James Pearson
2009-12-14 17:49 ` James Pearson [this message]
2009-12-18 13:43 ` Andrea Suisani
2009-12-18 14:12 ` Peter Zijlstra
2009-12-18 15:34 ` James Pearson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B267A9C.6010804@moving-picture.com \
--to=james-p@moving-picture.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox