Date: Wed, 12 Jul 2017 08:54:58 -0700
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
        Christoph Lameter <cl@linux.com>,
        "Li, Aubrey" <aubrey.li@linux.intel.com>,
        Andi Kleen <ak@linux.intel.com>, Aubrey Li <aubrey.li@intel.com>,
        tglx@linutronix.de, len.brown@intel.com, rjw@rjwysocki.net,
        tim.c.chen@linux.intel.com, arjan@linux.intel.com,
        yang.zhang.wz@gmail.com, x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods
Reply-To: paulmck@linux.vnet.ibm.com
References: <20170710084647.zs6wkl3fumszd33g@hirez.programming.kicks-ass.net>
 <20170710144609.GD31832@tassilo.jf.intel.com>
 <20170710164206.5aon5kelbisxqyxq@hirez.programming.kicks-ass.net>
 <20170710172705.GA3441@tassilo.jf.intel.com>
 <c6e62380-4995-f47e-acef-692e3b589862@linux.intel.com>
 <20170711094157.5xcwkloxnjehieqv@hirez.programming.kicks-ass.net>
 <20170711160926.GA18805@lerouge>
 <20170711163422.etydkhhtgfthpfi5@hirez.programming.kicks-ass.net>
 <20170711180931.GP2393@linux.vnet.ibm.com>
 <20170712122249.u6y4ymmk6qwvog57@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170712122249.u6y4ymmk6qwvog57@hirez.programming.kicks-ass.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-Id: <20170712155458.GW2393@linux.vnet.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1048
Lines: 25

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