All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linux PM <linux-pm@vger.kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Thomas Ilsche <thomas.ilsche@tu-dresden.de>,
	Doug Smythies <dsmythies@telus.net>,
	Rik van Riel <riel@surriel.com>,
	Aubrey Li <aubrey.li@linux.intel.com>,
	Mike Galbraith <mgalbraith@suse.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFT][PATCH v5 4/7] cpuidle: Return nohz hint from cpuidle_select()
Date: Mon, 19 Mar 2018 10:11:59 +0100	[thread overview]
Message-ID: <20180319091159.GF4043@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <2021405.tG9RYD54xL@aspire.rjw.lan>

On Thu, Mar 15, 2018 at 11:11:35PM +0100, Rafael J. Wysocki wrote:

I would suggest s/nohz_ret/stop_tick/ throughout, because I keep
forgetting which way around the boolean works and the new name doesn't
confuse.


> Index: linux-pm/drivers/cpuidle/governors/menu.c
> ===================================================================
> --- linux-pm.orig/drivers/cpuidle/governors/menu.c
> +++ linux-pm/drivers/cpuidle/governors/menu.c
> @@ -275,12 +275,16 @@ again:
>  	goto again;
>  }
>  
> +#define TICK_USEC_HZ   ((USEC_PER_SEC + HZ/2) / HZ)

Do we want to put that next to TICK_NSEC?

Also, there are only 2 users of the existing TICK_USEC, do we want to:

  s/TICK_USEC/USER_&/

and then rename the new thing to TICK_USEC ?

>  /**
>   * menu_select - selects the next idle state to enter
>   * @drv: cpuidle driver containing state data
>   * @dev: the CPU
> + * @nohz_ret: indication on whether or not to stop the tick
>   */
> +static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
> +		       bool *nohz_ret)
>  {
>  	struct menu_device *data = this_cpu_ptr(&menu_devices);
>  	struct device *device = get_cpu_device(dev->cpu);
> @@ -303,8 +307,10 @@ static int menu_select(struct cpuidle_dr
>  		latency_req = resume_latency;
>  
>  	/* Special case when user has set very strict latency requirement */
> +	if (unlikely(latency_req == 0)) {
> +		*nohz_ret = false;
>  		return 0;
> +	}
>  
>  	/* determine the expected residency time, round up */
>  	data->next_timer_us = ktime_to_us(tick_nohz_get_sleep_length());
> @@ -354,6 +360,7 @@ static int menu_select(struct cpuidle_dr
>  	if (latency_req > interactivity_req)
>  		latency_req = interactivity_req;
>  
> +	expected_interval = data->predicted_us;
>  	/*
>  	 * Find the idle state with the lowest power while satisfying
>  	 * our constraints.
> @@ -369,15 +376,30 @@ static int menu_select(struct cpuidle_dr
>  			idx = i; /* first enabled state */
>  		if (s->target_residency > data->predicted_us)
>  			break;
> +		if (s->exit_latency > latency_req) {
> +			/*
> +			 * If we break out of the loop for latency reasons, use
> +			 * the target residency of the selected state as the
> +			 * expected idle duration so that the tick is retained
> +			 * as long as that target residency is low enough.
> +			 */
> +			expected_interval = drv->states[idx].target_residency;
>  			break;
> +		}
>  		idx = i;
>  	}
>  
>  	if (idx == -1)
>  		idx = 0; /* No states enabled. Must use 0. */
>  
> +	/*
> +	 * Don't stop the tick if the selected state is a polling one or if the
> +	 * expected idle duration is shorter than the tick period length.
> +	 */
> +	if ((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) ||
> +	    expected_interval < TICK_USEC_HZ)
> +		*nohz_ret = false;
> +
>  	data->last_state_idx = idx;
>  
>  	return data->last_state_idx;

Yes, much clearer, Thanks!

  reply	other threads:[~2018-03-19  9:11 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 21:59 [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework Rafael J. Wysocki
2018-03-15 22:03 ` [RFT][PATCH v5 1/7] time: tick-sched: Reorganize idle tick management code Rafael J. Wysocki
2018-03-15 22:05 ` [RFT][PATCH v5 2/7] sched: idle: Do not stop the tick upfront in the idle loop Rafael J. Wysocki
2018-03-15 22:07 ` [RFT][PATCH v5 3/7] sched: idle: Do not stop the tick before cpuidle_idle_call() Rafael J. Wysocki
2018-03-15 22:11 ` [RFT][PATCH v5 4/7] cpuidle: Return nohz hint from cpuidle_select() Rafael J. Wysocki
2018-03-19  9:11   ` Peter Zijlstra [this message]
2018-03-19  9:39     ` Rafael J. Wysocki
2018-03-15 22:13 ` [RFT][PATCH v5 5/7] sched: idle: Select idle state before stopping the tick Rafael J. Wysocki
2018-03-15 22:16 ` [RFT][PATCH v5 6/7] cpuidle: menu: Refine idle state selection for running tick Rafael J. Wysocki
2018-03-19  9:45   ` Peter Zijlstra
2018-03-19  9:49     ` Rafael J. Wysocki
2018-03-15 22:19 ` [RFT][PATCH v5 7/7] cpuidle: menu: Avoid selecting shallow states with stopped tick Rafael J. Wysocki
2018-03-19 12:47   ` Thomas Ilsche
2018-03-19 18:21   ` Doug Smythies
2018-03-20 17:15   ` Doug Smythies
2018-03-20 17:28     ` Rafael J. Wysocki
2018-03-17 12:42 ` [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework Thomas Ilsche
2018-03-17 16:11 ` Doug Smythies
2018-03-18 11:00   ` Rafael J. Wysocki
2018-03-18 16:15     ` Rafael J. Wysocki
2018-03-19 10:49       ` Peter Zijlstra
2018-03-19 11:36         ` Rafael J. Wysocki
2018-03-19 11:58           ` Rafael J. Wysocki
2018-03-19 12:31           ` Peter Zijlstra
2018-03-20 10:01       ` Thomas Ilsche
2018-03-20 10:49         ` Rafael J. Wysocki
2018-03-20 17:15       ` Doug Smythies
2018-03-20 21:03       ` Doug Smythies
2018-03-21  6:33         ` Rafael J. Wysocki
2018-03-21 13:51         ` Doug Smythies
2018-03-21 13:58           ` Rafael J. Wysocki
2018-03-18 15:30   ` Doug Smythies
2018-03-18 16:06     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180319091159.GF4043@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=aubrey.li@linux.intel.com \
    --cc=dsmythies@telus.net \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgalbraith@suse.de \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=riel@surriel.com \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=thomas.ilsche@tu-dresden.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.