Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

[Paul E. McKenney]

On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote:
> From: Aubrey Li <aubrey.li@xxxxxxxxxxxxxxx>
> 
> The system will enter a fast idle loop if the predicted idle period
> is shorter than the threshold.
> ---
>  kernel/sched/idle.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index cf6c11f..16a766c 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -280,6 +280,8 @@ static void cpuidle_generic(void)
>   */
>  static void do_idle(void)
>  {
> +	unsigned int predicted_idle_us;
> +	unsigned int short_idle_threshold = jiffies_to_usecs(1) / 2;
>  	/*
>  	 * If the arch has a polling bit, we maintain an invariant:
>  	 *
> @@ -291,7 +293,12 @@ static void do_idle(void)
> 
>  	__current_set_polling();
> 
> -	cpuidle_generic();
> +	predicted_idle_us = cpuidle_predict();
> +
> +	if (likely(predicted_idle_us < short_idle_threshold))
> +		cpuidle_fast();

What if we get here from nohz_full usermode execution?  In that
case, if I remember correctly, the scheduling-clock interrupt
will still be disabled, and would have to be re-enabled before
we could safely invoke cpuidle_fast().

Or am I missing something here?

						Thanx, Paul

> +	else
> +		cpuidle_generic();
> 
>  	__current_clr_polling();
> 
> -- 
> 2.7.4
>