linux-kernel - Re: [PATCH tip/core/rcu] Do not keep timekeeping CPU tick running for non-nohz

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: <20140720221245.GA2138@lerouge>
Date:	Mon, 21 Jul 2014 00:12:48 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
	josh@...htriplett.org, tglx@...utronix.de, peterz@...radead.org,
	rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com,
	dvhart@...ux.intel.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH tip/core/rcu] Do not keep timekeeping CPU tick running
 for non-nohz_full= CPUs

On Sun, Jul 20, 2014 at 04:47:59AM -0700, Paul E. McKenney wrote:
> On Sat, Jul 19, 2014 at 08:01:24PM +0200, Frederic Weisbecker wrote:
> > On Sat, Jul 19, 2014 at 09:53:50AM -0700, Paul E. McKenney wrote:
> > > If a non-nohz_full= CPU is non-idle, it will have a scheduling-clock
> > > interrupt, and therefore doesn't need the timekeeping CPU to keep
> > > its scheduling-clock interrupt going.  This commit therefore ignores
> > > the idle state of non-nohz_full CPUs when determining whether or not
> > > the timekeeping CPU can safely turn off its scheduling-clock interrupt.
> > > 
> > > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > 
> > Unfortunately that's not how things work. Running a CPU tick doesn't necessarily
> > imply to run the timekeeping duty.
> > 
> > Only the timekeeper can update the timekeeping. There is an exception though:
> > the timekeeping is also updated by dynticks idle CPUs when they wake up in an
> > interrupt from idle.
> > 
> > Here is in practice why it doesn't work:
> > 
> > So lets say CPU 0 is timekeeper, CPU 1 a non-nohz-full CPU and all others are full-nohz.
> > CPU 0 is sleeping. CPU 1 wakes up from idle, so it has an uptodate timekeeping but then
> > if it continues to execute further without waking up CPU 0, it risks stale timestamps.
> > 
> > This can be changed by allowing timekeeping duty from all non-nohz_full CPUs, that's
> > the initial direction I took, but it involved a lot of complications and scalability
> > issues.
> 
> So we really have to have -all- the CPUs be idle to turn off the timekeeper.
> This won't make the battery-powered embedded guys happy...

I can imagine all sorts of solutions to solve this. None of them look simple
though. And I'm really convinced this isn't worth until some user comes up
and report me that 1) he seriously uses full dynticks and 2) he needs non-full-nohz
CPUs other than CPU 0.

If 1 and 2 ever happen, I'll gladly work on this.

> 
> Other thoughts on this?  We really should not be setting
> CONFIG_NO_HZ_FULL_SYSIDLE by default until this is solved.

Well it's better to save energy when all CPUs are idle than never.
--
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/