From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753453AbdJNBAo (ORCPT ); Fri, 13 Oct 2017 21:00:44 -0400 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:60438 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752769AbdJNBAn (ORCPT ); Fri, 13 Oct 2017 21:00:43 -0400 From: "Rafael J. Wysocki" To: Aubrey Li Cc: tglx@linutronix.de, peterz@infradead.org, len.brown@intel.com, ak@linux.intel.com, tim.c.chen@linux.intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, Aubrey Li Subject: Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle Date: Sat, 14 Oct 2017 02:51:10 +0200 Message-ID: <4523111.uMcC96MW3N@aspire.rjw.lan> In-Reply-To: <1506756034-6340-5-git-send-email-aubrey.li@intel.com> References: <1506756034-6340-1-git-send-email-aubrey.li@intel.com> <1506756034-6340-5-git-send-email-aubrey.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday, September 30, 2017 9:20:30 AM CEST Aubrey Li wrote: > If the next idle is expected to be a fast idle, we should keep tick > on before going into idle > > Signed-off-by: Aubrey Li This also can be merged with the previous patch (and the [2/8]) IMO. > --- > drivers/cpuidle/cpuidle.c | 14 ++++++++++++++ > include/linux/cpuidle.h | 2 ++ > kernel/time/tick-sched.c | 4 ++++ > 3 files changed, 20 insertions(+) > > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c > index ef6f7dd..6cb7e17 100644 > --- a/drivers/cpuidle/cpuidle.c > +++ b/drivers/cpuidle/cpuidle.c > @@ -370,6 +370,20 @@ void cpuidle_predict(void) > } > > /** > + * cpuidle_fast_idle - predict whether or not the coming idle is a fast idle > + * This function can be called in irq exit path, make it as soon as possible > + */ > +bool cpuidle_fast_idle(void) > +{ > + struct cpuidle_device *dev = cpuidle_get_device(); > + > + if (!dev) > + return false; > + > + return dev->idle_stat.fast_idle; return dev && dev->idle_stat.fast_idle; > +} > + > +/** > * cpuidle_install_idle_handler - installs the cpuidle idle loop handler > */ > void cpuidle_install_idle_handler(void) > diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h > index 9ca0288..791db15 100644 > --- a/include/linux/cpuidle.h > +++ b/include/linux/cpuidle.h > @@ -144,6 +144,7 @@ extern int cpuidle_select(struct cpuidle_driver *drv, > extern void cpuidle_entry_start(void); > extern void cpuidle_entry_end(void); > extern void cpuidle_predict(void); > +extern bool cpuidle_fast_idle(void); > extern int cpuidle_enter(struct cpuidle_driver *drv, > struct cpuidle_device *dev, int index); > extern void cpuidle_reflect(struct cpuidle_device *dev, int index); > @@ -180,6 +181,7 @@ static inline int cpuidle_select(struct cpuidle_driver *drv, > static inline void cpuidle_entry_start(void) { } > static inline void cpuidle_entry_end(void) { } > static inline void cpuidle_predict(void) { } > +static inline void cpuidle_fast_idle(void) {return false; } > static inline int cpuidle_enter(struct cpuidle_driver *drv, > struct cpuidle_device *dev, int index) > {return -ENODEV; } > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > index c7a899c..d663fab 100644 > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > > #include > > @@ -916,6 +917,9 @@ static bool can_stop_idle_tick(int cpu, struct tick_sched *ts) > return false; > } > > + if (cpuidle_fast_idle()) > + return false; > + > return true; return !cpuidle_fast_idle(); > } > > And IMO there is quite a bit too much marketing in the "fast_idle" name, as it seems all about avoiding to stop the tick if the predicted idle duration is short enough.