linux-kernel - Re: [PATCH 04/32] nohz: Separate idle sleeping time accounting from nohz switching

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: <1314627800.2816.62.camel@twins>
Date:	Mon, 29 Aug 2011 16:23:19 +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 04/32] nohz: Separate idle sleeping time accounting from
 nohz switching

On Mon, 2011-08-15 at 17:52 +0200, Frederic Weisbecker wrote:
> To prepare for having nohz mode switching independant from idle,
> pull the idle sleeping time accounting out of the tick stop API.
> 
> This implies to implement some new API to call when we
> enter/exit idle. 

I mean, I really love brevity, but you seem to just not state all the
important bits ;-)

So the goal is to disable the tick more often (say when running 1
userbound task), why does that need new hooks? If we already had the
tick disabled, the tick_nohz_stop_sched_tick() call on going idle will
simply not do anything.

If we go from idle to running something we want to enable the tick
initially because doing the task wakeup involves RCU etc.. Once we find
the task is indeed userbound and we've finished all our state we can
disable the thing again.


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