On 2017/10/14 8:51, Rafael J. Wysocki wrote: > 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 <aubrey...@linux.intel.com> > > This also can be merged with the previous patch (and the [2/8]) IMO. >
okay, will merge in the next version. >> --- >> 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; Thanks! >> >> @@ -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 thanks! > >> } >> >> > > 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. > okay, and what's your suggestion? :) I'll try to move quiet_vmstat() into the normal idle branch if this patch series are reasonable. Is fast_idle a good indication for it? Thanks, -Aubrey