All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Christian Loehle <christian.loehle@arm.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	rafael@kernel.org
Cc: vincent.guittot@linaro.org, qyousef@layalina.io,
	peterz@infradead.org, daniel.lezcano@linaro.org,
	ulf.hansson@linaro.org, anna-maria@linutronix.de,
	kajetan.puchalski@arm.com, lukasz.luba@arm.com
Subject: Re: [PATCHv2 2/3] cpuidle: teo: Remove recent intercepts metric
Date: Wed, 26 Jun 2024 12:44:01 +0200	[thread overview]
Message-ID: <06231a07-c470-4156-bada-41b346b280cb@arm.com> (raw)
In-Reply-To: <20240611112413.1241352-3-christian.loehle@arm.com>

On 11/06/2024 13:24, Christian Loehle wrote:
> The logic for recent intercepts didn't work, there is an underflow
> of the 'recent' value that can be observed during boot already, which
> teo usually doesn't recover from, making the entire logic pointless.
> Furthermore the recent intercepts also were never reset, thus not
> actually being very 'recent'.
> 
> Having underflowed 'recent' values lead to teo always acting as if
> we were in a scenario were expected sleep length based on timers is
> too high and it therefore unnecessarily selecting shallower states.
> 
> Experiments show that the remaining 'intercept' logic is enough to
> quickly react to scenarios in which teo cannot rely on the timer
> expected sleep length.
> 
> See also here:
> https://lore.kernel.org/lkml/0ce2d536-1125-4df8-9a5b-0d5e389cd8af@arm.com/

So the fixes proposed in teo_update() there:

(1) add '&& cpu_data->state_bins[cpu_data->recent_idx[i]].recent' to the 
    if condition to decrement 'cpu_data->state_bins[].recent' or

(2) Set 'cpu_data->state_bins[].recent' = 0 instead of decrement

didn't work?

> Fixes: 77577558f25d ("cpuidle: teo: Rework most recent idle duration values treatment")
> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
> ---
>  drivers/cpuidle/governors/teo.c | 73 ++++++---------------------------
>  1 file changed, 12 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/cpuidle/governors/teo.c b/drivers/cpuidle/governors/teo.c
> index d8554c20cf10..cc7df59f488d 100644
> --- a/drivers/cpuidle/governors/teo.c
> +++ b/drivers/cpuidle/governors/teo.c
> @@ -59,10 +59,6 @@
>   * shallower than the one whose bin is fallen into by the sleep length (these
>   * situations are referred to as "intercepts" below).
>   *
> - * In addition to the metrics described above, the governor counts recent
> - * intercepts (that is, intercepts that have occurred during the last
> - * %NR_RECENT invocations of it for the given CPU) for each bin.
> - *
>   * In order to select an idle state for a CPU, the governor takes the following
>   * steps (modulo the possible latency constraint that must be taken into account
>   * too):
> @@ -81,20 +77,15 @@

 66  * 1. Find the deepest CPU idle state whose target residency does not exceed
 67  *    the current sleep length (the candidate idle state) and compute 3 sums as

s/3/2 ?

[...]

> @@ -320,8 +288,6 @@ static int teo_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
>  	unsigned int tick_intercept_sum = 0;
>  	unsigned int idx_intercept_sum = 0;
>  	unsigned int intercept_sum = 0;
> -	unsigned int idx_recent_sum = 0;
> -	unsigned int recent_sum = 0;
>  	unsigned int idx_hit_sum = 0;
>  	unsigned int hit_sum = 0;
>  	int constraint_idx = 0;

Looks like 'bool alt_intercepts, alt_recent' have to go here already and
not in 3/3.

[...]

  reply	other threads:[~2024-06-26 10:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11 11:24 [PATCHv2 0/3] cpuidle: teo: Fixing utilization and intercept logic Christian Loehle
2024-06-11 11:24 ` [PATCHv2 1/3] Revert: "cpuidle: teo: Introduce util-awareness" Christian Loehle
2024-06-11 13:37   ` Vincent Guittot
2024-06-19 17:49   ` Qais Yousef
2024-06-21 13:22   ` [PATCHv3 " Christian Loehle
2024-06-11 11:24 ` [PATCHv2 2/3] cpuidle: teo: Remove recent intercepts metric Christian Loehle
2024-06-26 10:44   ` Dietmar Eggemann [this message]
2024-06-26 12:41     ` Christian Loehle
2024-06-11 11:24 ` [PATCHv2 3/3] cpuidle: teo: Don't count non-existent intercepts Christian Loehle
2024-06-26 13:09   ` Dietmar Eggemann
2024-06-28  9:33     ` Christian Loehle
2024-06-17  0:20 ` [PATCHv2 0/3] cpuidle: teo: Fixing utilization and intercept logic Doug Smythies
2024-06-18 11:17   ` Christian Loehle
2024-06-18 17:24     ` Doug Smythies
2024-06-20 11:19       ` Christian Loehle
2024-06-25 16:35         ` Doug Smythies

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=06231a07-c470-4156-bada-41b346b280cb@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=anna-maria@linutronix.de \
    --cc=christian.loehle@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=kajetan.puchalski@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=peterz@infradead.org \
    --cc=qyousef@layalina.io \
    --cc=rafael@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=vincent.guittot@linaro.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 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.