linux-kernel - Re: [PATCH 1/6] hrtimer: Provide clock_was_set

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: <4FFDAE1D.3050008@us.ibm.com>
Date:	Wed, 11 Jul 2012 09:47:25 -0700
From:	John Stultz <johnstul@...ibm.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Prarit Bhargava <prarit@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>, stable@...r.kernel.org
Subject: Re: [PATCH 1/6] hrtimer: Provide clock_was_set_delayed()

On 07/11/2012 08:18 AM, Thomas Gleixner wrote:
> That leaves NOHZ enabled systems and there we might be clever and
> avoid the IPIs to those cores which are not idle and let the tick
> interrupt deal with it. And we can make the calls async and just let
> them raise the hrtimer softirq on those cores, which will run the
> hrtimer interrupt code and take care of everything.

I'm not familiar with the details of the code that tracks which cores 
are idle or not, but I'd worry with this approach that there might be 
further races in determining which cores are idle and which cores are 
about to go idle with stale base offsets.

I'll see if my worry is unfounded, but it might be a bit too clever for 
rare events.

thanks
-john

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