linux-kernel - Re: nmi_watchdog=2 regression in 2.6.21

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]

Date:	Fri, 31 Aug 2007 18:36:07 -0700
From:	Daniel Walker <dwalker@...sta.com>
To:	Björn Steinbrink <B.Steinbrink@....de>
Cc:	eranian@....hp.com, ak@...e.de, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: nmi_watchdog=2 regression in 2.6.21

On Sat, 2007-09-01 at 03:00 +0200, Björn Steinbrink wrote:
> On 2007.08.31 17:24:46 -0700, Daniel Walker wrote:
> > On Fri, 2007-08-31 at 20:06 +0200, Björn Steinbrink wrote:
> > 
> > 
> > > > something to do with the nmi hertz adjustment that happens after
> > > > check_nmi_watchdog() ..
> > > 
> > > Hm hm, does the same thing (watchdog stuck after check) happen with
> > > older kernels, ie. those before Stephane's changeset that made it use
> > > PERFCTR1?
> > 
> > I noticed the frequency gets turned down after check_nmi_watchdog() is
> > called.. I think it's suppose to trigger once per second, but it's more
> > like it updates randomly ..
> 
> It's once per second if the cpu is 100% busy, if it's just idling and
> halted, the performance counters won't be increased.

Didn't know that .. I ran hackbench while watching /proc/interrupts ,
and it ticks along ok on some cores .. 

The acid test was running an application that hangs the system, and it
caught it (although the system didn't recover from the lockup..) ..

> > In older kernels it's very slow, but it's more consistent ..
> 
> With the same load on the box? Maybe some other changes caused the box
> to behave differently (say, CFS), regarding eg. load distribution
> amongst the cores.

It must not have been the same load considering everything else.

I'm satisfied that Stephane's last patch fixes it ..

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/