Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932667AbdGLMXA (ORCPT ); Wed, 12 Jul 2017 08:23:00 -0400 Received: from merlin.infradead.org ([205.233.59.134]:33036 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932308AbdGLMW6 (ORCPT ); Wed, 12 Jul 2017 08:22:58 -0400 Date: Wed, 12 Jul 2017 14:22:49 +0200 From: Peter Zijlstra To: "Paul E. McKenney" Cc: Frederic Weisbecker , Christoph Lameter , "Li, Aubrey" , Andi Kleen , Aubrey Li , 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 Message-ID: <20170712122249.u6y4ymmk6qwvog57@hirez.programming.kicks-ass.net> References: <1499650721-5928-1-git-send-email-aubrey.li@intel.com> <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> <20170711094157.5xcwkloxnjehieqv@hirez.programming.kicks-ass.net> <20170711160926.GA18805@lerouge> <20170711163422.etydkhhtgfthpfi5@hirez.programming.kicks-ass.net> <20170711180931.GP2393@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170711180931.GP2393@linux.vnet.ibm.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 649 Lines: 13 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?