lkml.org 
[lkml]   [2018]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick
On Sun, Mar 04, 2018 at 11:28:56PM +0100, Rafael J. Wysocki wrote:
> Index: linux-pm/kernel/sched/idle.c
> ===================================================================
> --- linux-pm.orig/kernel/sched/idle.c
> +++ linux-pm/kernel/sched/idle.c
> @@ -188,13 +188,14 @@ static void cpuidle_idle_call(void)
> } else {
> unsigned int duration_us;
>
> - tick_nohz_idle_go_idle(true);
> - rcu_idle_enter();
> -
> /*
> * Ask the cpuidle framework to choose a convenient idle state.
> */
> next_state = cpuidle_select(drv, dev, &duration_us);
> +
> + tick_nohz_idle_go_idle(duration_us > USEC_PER_SEC / HZ);
> + rcu_idle_enter();
> +
> entered_state = call_cpuidle(drv, dev, next_state);
> /*
> * Give the governor an opportunity to reflect on the outcome

So I think this is entirely wrong, I would much rather see something
like:

tick_nohz_idle_go_idle(next_state->nohz);

Where the selected state itself has the nohz property or not.

We can always insert an extra state at whatever the right boundary point
is for nohz if it doesn't line up with an existing point.

\
 
 \ /
  Last update: 2018-03-05 12:46    [W:0.157 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site