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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101003171823.GA19129@roll>
Date:	Sun, 3 Oct 2010 13:18:23 -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>
Subject: Re: PROBLEM: Unusually high load average when idle in 2.6.35, 2.6.35.1 and later

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

Content of type "application/pgp-signature" skipped