Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Mon, 5 Mar 2018 12:50:03 +0100 | Subject | Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick |
| |
On Mon, Mar 5, 2018 at 12:45 PM, Peter Zijlstra <peterz@infradead.org> wrote: > 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.
Can you elaborate here, I'm not following?
> 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.
| |