Re: PROBLEM: Unusually high load average when idle in 2.6.35, 2.6.35.1 and later

[tmhikaru@gmail.com]

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

On Sun, Oct 03, 2010 at 01:18:23PM -0400, tm@ wrote:
> I screwed up and sent this incorrectly to only Peter originally, resent to
> everyone else too.
> 
> On Sun, Oct 03, 2010 at 02:04:38PM +0200, Peter Zijlstra wrote:
> > On Sun, 2010-10-03 at 12:12 +0200, Florian Mickler wrote:
> > > On Sun, 03 Oct 2010 10:41:08 +0200
> > > Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > > On Sat, 2010-10-02 at 23:02 -0400, tmhikaru@gmail.com wrote:
> > > > >  The load average statistic is indeed broken somehow, and I
> > > > > did bisect it down to where the problem began, however there seems
> > > > >  to be no
> > > > > performance problem related to it I can find.
> > > >
> > > > Chase, anything you can see broken with this stuff?
> > >
> > > Peter, do you think it would be worthwile to test a kernel with the
> > > low load-averages in NOHZ=disable mode? The bisected commit claims to
> > > fix a NOHZ issue with the load average. So if the new figures are the
> > > correct ones, they should be somehow similar to the figures before
> > > with NOHZ? Or am I on the wrong track here?
> >
> > No, that makes sense, but there is of course the distinct possibility
> > that the patch wrecked the !nohz path as well. So ideally you'd have to
> > compare NOHZ=n with this patch reverted and NOHZ=y with this patch in
> > place.
> >
> 
> That'd be easy for me to do if you want. given I use CONFIG_NO_HZ=y
> in my kernel .config, that's tested the 'patch already in place' path right?
> I'll try setting up a kernel build with CONFIG_NO_HZ=n if that's what you
> want me to test. I unfortunately am not entirely sure if that's what I need
> to alter though, so please get back to me and let me know so I can test it.
> 
> Tim McGrath


I haven't heard any feedback from anyone about this since I sent this
message. Is there anything else I can do to help nail this problem, is it
already solved, or ... what? What's going on?

Tim McGrath

[-- Attachment #2: Type: application/pgp-signature, Size: 482 bytes --]