On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote:
> From: Aubrey Li <aubrey...@linux.intel.com>
>
> 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
>
