linux-kernel - Re: [PATCH 09/32] nohz: Move ts->idle

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: <1314642803.2816.138.camel@twins>
Date:	Mon, 29 Aug 2011 20:33:23 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Anton Blanchard <anton@....ibm.com>,
	Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
	Paul Menage <menage@...gle.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tim Pepper <lnxninja@...ux.vnet.ibm.com>
Subject: Re: [PATCH 09/32] nohz: Move ts->idle_calls into strict idle logic

On Mon, 2011-08-29 at 20:23 +0200, Frederic Weisbecker wrote:

> > Well, no, on interrupt return you shouldn't do anything. If you've
> > stopped the tick it stays stopped until you do something that needs it,
> > then that action will re-enable it.
> 
> Sure, when something needs the tick in this mode, we usually
> receive an IPI and restart the tick from there but then
> tick_nohz_stop_sched_tick() handles the cases with *needs_cpu()
> very well on interrupt return (our IPI return) by doing a kind
> of "light" HZ mode by logically switching to nohz mode but
> with the next timer happening in HZ, assuming it's a matter
> of one tick and we will switch to a real nohz behaviour soon.
> 
> I don't see a good reason to duplicate that logic with a pure
> restart from the IPI.

That sounds like an optimization, and should thus be done later.

> > > That said I wonder if some of the above conditions should restore a periodic
> > > behaviour on interrupt return...
> > 
> > I would expect the tick not to be stopped when tick_nohz_can_stop_tick()
> > returns false. If it returns true, then I expect anything that needs it
> > to re-enable it.
> > 
> 
> Yeah. In the case of need_resched() in idle I believe the CPU doesn't
> really go to sleep later so it should be fine. But for the case of
> softirq pending or nohz_mode, I'm not sure...

softirqs shouldn't be pending when you go into nohz mode..

That is, I'm really not seeing what's wrong with the very simple:


  if (tick_nohz_can_stop_tick())
	tick_nohz_stop_tick();


and relying on everybody who invalidates tick_nohz_can_stop_tick(), to
do:

  tick_nohz_start_tick();

I'm also not quite sure why you always IPI, is that to avoid lock
inversions?
--
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/