linux-kernel - Re: [PATCH] specific do_timer

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:	Wed, 15 Feb 2012 21:36:47 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Dimitri Sivanich <sivanich@....com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] specific do_timer_cpu value for nohz off mode

On Wed, 15 Feb 2012, Dimitri Sivanich wrote:
> On Wed, Feb 15, 2012 at 03:52:06PM +0100, Thomas Gleixner wrote:
> > So the first CPU which registers a clock event device takes it. That's
> > the boot CPU, no matter what.
> >
> Both kernel tracing and the original patch that I proposed for this
> showed plainly (at the time) that the tick_do_timer_cpu was not always cpu 0
> prior to modifying it for nohz=off.  Maybe that is no longer the case?

This logic has not been changed in years.

tick_do_timer_cpu is initialized to TICK_DO_TIMER_BOOT and the first
cpu which registers either a global or a per cpu clock event device
takes it over. This is at least on x86 always the boot cpu, i.e. cpu0.
After that point nothing touches that variable when nohz is disabled
(runtime or compile time).

So I really want to see proper proof why that would not be the
case. If it really happens then we fix the root cause instead of
adding random sysfs interfaces.

Thanks,

	tglx
--
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/