linux-kernel - Re: vmstat: On demand vmstat workers V4

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:	Sat, 10 May 2014 18:38:54 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Christoph Lameter <cl@...ux.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Gilad Ben-Yossef <gilad@...yossef.com>,
	Tejun Heo <tj@...nel.org>, Mike Frysinger <vapier@...too.org>,
	Minchan Kim <minchan.kim@...il.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	Max Krasnyansky <maxk@...lcomm.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
	hughd@...gle.com, viresh.kumar@...aro.org,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	John Stultz <john.stultz@...aro.org>
Subject: Re: vmstat: On demand vmstat workers V4

On Sun, May 11, 2014 at 03:30:31AM +0200, Frederic Weisbecker wrote:
> On Sat, May 10, 2014 at 06:17:08PM -0700, Paul E. McKenney wrote:
> > On Sat, May 10, 2014 at 03:14:25PM +0200, Frederic Weisbecker wrote:
> > > On Sat, May 10, 2014 at 02:31:28PM +0200, Thomas Gleixner wrote:
> > > > On Sat, 10 May 2014, Frederic Weisbecker wrote:
> > > > > But I still have the plan to make the timekeeper use the full sysidle
> > > > > facility in order to adaptively get to dynticks idle.
> > > > > 
> > > > > Reminder for others: in NO_HZ_FULL, the timekeeper (always CPU 0) stays
> > > > > completely periodic. It can't enter in dynticks idle mode because it
> > > > > must maintain timekeeping on behalf of full dynticks CPUs. So that's
> > > > > a power issue.
> > > > > 
> > > > > But Paul has a feature in RCU that lets us know when all CPUs are idle
> > > > > and the timekeeper can finally sleep. Then when a full nohz CPU wakes
> > > > > up from idle, it sends an IPI to the timekeeper if needed so the latter
> > > > > restarts timekeeping maintainance.
> > > > >
> > > > > It's not complicated to add to the timer code.
> > > > > Most of the code is already there, in RCU, for a while already.
> > > > > 
> > > > > Are we keeping that direction? 
> > > > 
> > > > So the idea is that the timekeeper stays on cpu0, but if everything is
> > > > idle it is allowed to take a long nap as well. So if some other cpu
> > > > wakes up it updates timekeeping without taking over the time keeper
> > > > duty and if it has work to do, it kicks cpu0 into gear. If it just
> > > > goes back to sleep, then nothing to do.
> > 
> > Hmmm...  If RCU is supposed to ignore the fact that one of the other
> > CPUs woke up momentarily, we will need to adjust things a bit.
> 
> Maybe not that much actually.
> 
> > 
> > > Exactly! Except perhaps the last sentence "If it just goes back to sleep,
> > > then nothing to do.", I didn't think about that although this special case
> > > is quite frequent indeed when an interrupt fires on idle but no task is woken up.
> > > 
> > > Maybe I should move the code that fires the IPI to cpu0, if it is sleeping,
> > > on irq exit (the plan was to do it right away on irq enter) and fire it
> > > only if need_resched().
> > 
> > And of course if that code path contains any RCU read-side critical
> > sections, RCU absolutely cannot ignore that CPU's momentary wakeup.
> 
> Sure the core RCU still needs to know that the CPU went out of dynticks the
> time of the irq, so we keep the rcu_irq_enter/rcu_irq_exit calls.
> 
> But if the CPU only wakes up to serve an IRQ, it doesn't need to tell the RCU
> sysidle detection about it. The irq entry fixup jiffies on dynticks idle mode,
> this should be enough.

As long as you pass me in a hint so that RCU knows which case it is
dealing with.  ;-)

							Thanx, Paul

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