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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170711125847.GA13265@linux.vnet.ibm.com>
Date:   Tue, 11 Jul 2017 05:58:47 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Aubrey Li <aubrey.li@...el.com>
Cc:     tglx@...utronix.de, peterz@...radead.org, len.brown@...el.com,
        rjw@...ysocki.net, ak@...ux.intel.com, tim.c.chen@...ux.intel.com,
        arjan@...ux.intel.com, yang.zhang.wz@...il.com, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Aubrey Li <aubrey.li@...ux.intel.com>, fweisbec@...il.com
Subject: Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for
 short idle periods

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