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
| ||
|
Date: Wed, 12 Jul 2017 08:54:58 -0700 From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> To: Peter Zijlstra <peterz@...radead.org> Cc: Frederic Weisbecker <fweisbec@...il.com>, Christoph Lameter <cl@...ux.com>, "Li, Aubrey" <aubrey.li@...ux.intel.com>, Andi Kleen <ak@...ux.intel.com>, Aubrey Li <aubrey.li@...el.com>, tglx@...utronix.de, len.brown@...el.com, rjw@...ysocki.net, tim.c.chen@...ux.intel.com, arjan@...ux.intel.com, yang.zhang.wz@...il.com, x86@...nel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods On Wed, Jul 12, 2017 at 02:22:49PM +0200, Peter Zijlstra wrote: > On Tue, Jul 11, 2017 at 11:09:31AM -0700, Paul E. McKenney wrote: > > On Tue, Jul 11, 2017 at 06:34:22PM +0200, Peter Zijlstra wrote: > > > Also, RCU_FAST_NO_HZ will make a fairly large difference here.. Paul > > > what's the state of that thing, do we actually want that or not? > > > > If you are battery powered and don't have tight real-time latency > > constraints, you want it -- it has represent a 30-40% boost in battery > > lifetime for some low-utilization battery-powered devices. Otherwise, > > probably not. > > Would it make sense to hook that off of tick_nohz_idle_enter(); in > specific the part where we actually stop the tick; instead of every > idle? The actions RCU takes on RCU_FAST_NO_HZ depend on the current state of the CPU's callback lists, so it seems to me that the decision has to be made on each idle entry. Now it might be possible to make the checks more efficient, and doing that is on my list. Or am I missing your point? Thanx, Paul
Powered by blists - more mailing lists