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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20101011010956.GA7334@roll>
Date:	Sun, 10 Oct 2010 21:09:56 -0400
From:	tmhikaru@...il.com
To:	linux-kernel@...r.kernel.org, Greg KH <gregkh@...e.de>,
	Chase Douglas <chase.douglas@...onical.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: PROBLEM: Unusually high load average when idle in 2.6.35, 2.6.35.1 and later

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@...radead.org> wrote:
> > >
> > > > On Sat, 2010-10-02 at 23:02 -0400, tmhikaru@...il.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
Content of type "application/pgp-signature" skipped