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

From: Rik van Riel <riel@surriel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Frederic Weisbecker <fweisbec@gmail.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Thomas Ilsche <thomas.ilsche@tu-dresden.de>,
	Doug Smythies <dsmythies@telus.net>,
	Aubrey Li <aubrey.li@linux.intel.com>,
	Mike Galbraith <mgalbraith@suse.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>
Subject: Re: [RFC/RFT][PATCH 6/7] sched: idle: Predict idle duration before stopping the tick
Date: Mon, 05 Mar 2018 18:27:01 -0500	[thread overview]
Message-ID: <1520292421.6857.22.camel@surriel.com> (raw)
In-Reply-To: <2048240.1dZKXsSxFh@aspire.rjw.lan>

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]