public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Aubrey Li <aubrey.li@intel.com>
Cc: tglx@linutronix.de, peterz@infradead.org, len.brown@intel.com,
	ak@linux.intel.com, tim.c.chen@linux.intel.com, x86@kernel.org,
	linux-kernel@vger.kernel.org,
	Aubrey Li <aubrey.li@linux.intel.com>
Subject: Re: [RFC PATCH v2 1/8] cpuidle: menu: extract prediction functionality
Date: Sat, 14 Oct 2017 02:26:50 +0200	[thread overview]
Message-ID: <1629755.KbDSmDPDTX@aspire.rjw.lan> (raw)
In-Reply-To: <1506756034-6340-2-git-send-email-aubrey.li@intel.com>

On Saturday, September 30, 2017 9:20:27 AM CEST Aubrey Li wrote:
> There are several factors in the menu governor to predict the next
> idle interval:
> - the next timer
> - the recent idle interval history
> - the corrected idle interval pattern
> These factors are common enough to be extracted to be one function.
> 
> Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>

This patch alone would break things AFAICS, because it removes code from
menu_select() without a replacement (and menu_predict() is never called
just yet).

Please always do your best to ensure that things will work after *every*
patch in a series.

> ---
>  drivers/cpuidle/governors/menu.c | 64 +++++++++++++++++++++++++---------------
>  1 file changed, 40 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
> index 61b64c2..6bed197 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -276,6 +276,45 @@ static unsigned int get_typical_interval(struct menu_device *data)
>  }
>  
>  /**
> + * menu_predict - predict the coming idle interval
> + *
> + * Return the predicted coming idle interval in micro-second
> + */
> +static unsigned int menu_predict(void)
> +{
> +	struct menu_device *data = this_cpu_ptr(&menu_devices);
> +	unsigned int expected_interval;
> +	int cpu = smp_processor_id();
> +
> +	if (!data)
> +		return UINT_MAX;
> +
> +	/* determine the expected residency time, round up */
> +	data->next_timer_us = ktime_to_us(tick_nohz_get_sleep_length());
> +
> +	data->bucket = which_bucket(data->next_timer_us, nr_iowait_cpu(cpu));
> +
> +	/*
> +	 * Force the result of multiplication to be 64 bits even if both
> +	 * operands are 32 bits.
> +	 * Make sure to round up for half microseconds.
> +	 */
> +	data->predicted_us = DIV_ROUND_CLOSEST_ULL((uint64_t)
> +		data->next_timer_us * data->correction_factor[data->bucket],
> +		RESOLUTION * DECAY);
> +
> +	expected_interval = get_typical_interval(data);
> +	expected_interval = min(expected_interval, data->next_timer_us);
> +
> +	/*
> +	 * Use the lowest expected idle interval to pick the idle state.
> +	 */
> +	data->predicted_us = min(data->predicted_us, expected_interval);
> +
> +	return data->predicted_us;
> +}
> +
> +/**
>   * menu_select - selects the next idle state to enter
>   * @drv: cpuidle driver containing state data
>   * @dev: the CPU
> @@ -289,7 +328,6 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
>  	int first_idx;
>  	int idx;
>  	unsigned int interactivity_req;
> -	unsigned int expected_interval;
>  	unsigned long nr_iowaiters, cpu_load;
>  	int resume_latency = dev_pm_qos_raw_read_value(device);
>  
> @@ -306,24 +344,6 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
>  	if (unlikely(latency_req == 0))
>  		return 0;
>  
> -	/* determine the expected residency time, round up */
> -	data->next_timer_us = ktime_to_us(tick_nohz_get_sleep_length());
> -
> -	get_iowait_load(&nr_iowaiters, &cpu_load);
> -	data->bucket = which_bucket(data->next_timer_us, nr_iowaiters);
> -
> -	/*
> -	 * Force the result of multiplication to be 64 bits even if both
> -	 * operands are 32 bits.
> -	 * Make sure to round up for half microseconds.
> -	 */
> -	data->predicted_us = DIV_ROUND_CLOSEST_ULL((uint64_t)data->next_timer_us *
> -					 data->correction_factor[data->bucket],
> -					 RESOLUTION * DECAY);
> -
> -	expected_interval = get_typical_interval(data);
> -	expected_interval = min(expected_interval, data->next_timer_us);
> -
>  	if (CPUIDLE_DRIVER_STATE_START > 0) {
>  		struct cpuidle_state *s = &drv->states[CPUIDLE_DRIVER_STATE_START];
>  		unsigned int polling_threshold;
> @@ -345,14 +365,10 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
>  	}
>  
>  	/*
> -	 * Use the lowest expected idle interval to pick the idle state.
> -	 */
> -	data->predicted_us = min(data->predicted_us, expected_interval);
> -
> -	/*
>  	 * Use the performance multiplier and the user-configurable
>  	 * latency_req to determine the maximum exit latency.
>  	 */
> +	get_iowait_load(&nr_iowaiters, &cpu_load);
>  	interactivity_req = data->predicted_us / performance_multiplier(nr_iowaiters, cpu_load);
>  	if (latency_req > interactivity_req)
>  		latency_req = interactivity_req;
> 

  reply	other threads:[~2017-10-14  0:36 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-30  7:20 [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality Aubrey Li
2017-09-30  7:20 ` [RFC PATCH v2 1/8] cpuidle: menu: extract " Aubrey Li
2017-10-14  0:26   ` Rafael J. Wysocki [this message]
2017-10-16  2:46     ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 2/8] cpuidle: record the overhead of idle entry Aubrey Li
2017-10-14  0:35   ` Rafael J. Wysocki
2017-10-16  3:11     ` Li, Aubrey
2017-10-17  0:05       ` Rafael J. Wysocki
2017-10-17  7:04         ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 3/8] cpuidle: add a new predict interface Aubrey Li
2017-10-14  0:45   ` Rafael J. Wysocki
2017-10-16  8:04     ` Li, Aubrey
2017-10-14  1:27   ` Rafael J. Wysocki
2017-10-16  9:52     ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle Aubrey Li
2017-10-14  0:51   ` Rafael J. Wysocki
2017-10-16  3:26     ` Li, Aubrey
2017-10-16  4:45       ` Mike Galbraith
2017-10-16  5:34         ` Li, Aubrey
2017-10-16  6:25           ` Mike Galbraith
2017-10-16  6:31             ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 5/8] timers: keep sleep length updated as needed Aubrey Li
2017-10-14  0:56   ` Rafael J. Wysocki
2017-10-16  6:46     ` Li, Aubrey
2017-10-16 23:58       ` Rafael J. Wysocki
2017-10-17  6:10         ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 6/8] cpuidle: make fast idle threshold tunable Aubrey Li
2017-10-14  0:59   ` Rafael J. Wysocki
2017-10-16  6:00     ` Li, Aubrey
2017-10-17  0:01       ` Rafael J. Wysocki
2017-10-17  6:12         ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 7/8] cpuidle: introduce irq timing to make idle prediction Aubrey Li
2017-10-14  1:01   ` Rafael J. Wysocki
2017-10-16  6:03     ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 8/8] cpuidle: introduce run queue average idle " Aubrey Li
2017-10-14  1:02   ` Rafael J. Wysocki
2017-10-14  1:14 ` [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality Rafael J. Wysocki
2017-10-16  7:44   ` Li, Aubrey
2017-10-17  0:07     ` Rafael J. Wysocki
2017-10-17  7:32       ` Li, Aubrey
2017-11-30  1:00 ` Li, Aubrey
2017-11-30  1:37   ` 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=1629755.KbDSmDPDTX@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=ak@linux.intel.com \
    --cc=aubrey.li@intel.com \
    --cc=aubrey.li@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox