Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick

From: Rik van Riel
Date: Mon Mar 05 2018 - 18:27:18 EST


On Sun, 2018-03-04 at 23:28 +0100, Rafael J. Wysocki wrote:
>
> +++ 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);

When the expected idle period is short enough
that the timer is not stopped, does it make
sense to still call rcu_idle_enter?

Should rcu_idle_enter also be conditional on
the expected idle period?

--
All Rights Reversed.

Attachment: signature.asc
Description: This is a digitally signed message part