linux-kernel - Re: [PATCH 3/3] cpuidle: teo: Don't count non-existent intercepts

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]

Date: Fri, 28 Jun 2024 20:48:19 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Christian Loehle <christian.loehle@....com>
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org, rafael@...nel.org, 
	vincent.guittot@...aro.org, qyousef@...alina.io, peterz@...radead.org, 
	daniel.lezcano@...aro.org, ulf.hansson@...aro.org, anna-maria@...utronix.de, 
	dsmythies@...us.net, kajetan.puchalski@....com, lukasz.luba@....com, 
	dietmar.eggemann@....com
Subject: Re: [PATCH 3/3] cpuidle: teo: Don't count non-existent intercepts

On Fri, Jun 28, 2024 at 12:02 PM Christian Loehle
<christian.loehle@....com> wrote:
>
> When bailing out early, teo will not query the sleep length anymore
> since commit 6da8f9ba5a87 ("cpuidle: teo:
> Skip tick_nohz_get_sleep_length() call in some cases") with an
> expected sleep_length_ns value of KTIME_MAX.
> This lead to state0 accumulating lots of 'intercepts' because
> the actually measured sleep length was < KTIME_MAX, so query the sleep
> length instead for teo to recognize if it still is in an
> intercept-likely scenario without alternating between the two modes.
>
> Fundamentally we can only do one of the two:
> 1. Skip sleep_length_ns query when we think intercept is likely
> 2. Have accurate data if sleep_length_ns is actually intercepted when
> we believe it is currently intercepted.
>
> Previously teo did the former while this patch chooses the latter as
> the additional time it takes to query the sleep length was found to be
> negligible and the variants of option 1 (count all unknowns as misses
> or count all unknown as hits) had significant regressions (as misses
> had lots of too shallow idle state selections and as hits had terrible
> performance in intercept-heavy workloads).
>
> Fixes: 6da8f9ba5a87 ("cpuidle: teo: Skip tick_nohz_get_sleep_length() call in some cases")
> Signed-off-by: Christian Loehle <christian.loehle@....com>
> ---
> v3:
> Drop counting KTIME_MAX as hit and reword commit accordingly
>
>  drivers/cpuidle/governors/teo.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/cpuidle/governors/teo.c b/drivers/cpuidle/governors/teo.c
> index 200a3598cbcf..c2d73507d23b 100644
> --- a/drivers/cpuidle/governors/teo.c
> +++ b/drivers/cpuidle/governors/teo.c
> @@ -287,6 +287,7 @@ static int teo_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
>         unsigned int hit_sum = 0;
>         int constraint_idx = 0;
>         int idx0 = 0, idx = -1;
> +       int prev_intercept_idx;
>         s64 duration_ns;
>         int i;
>
> @@ -364,6 +365,7 @@ static int teo_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
>          * all of the deeper states a shallower idle state is likely to be a
>          * better choice.
>          */
> +       prev_intercept_idx = idx;
>         if (2 * idx_intercept_sum > cpu_data->total - idx_hit_sum) {
>                 int first_suitable_idx = idx;
>
> @@ -415,6 +417,14 @@ static int teo_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
>                         first_suitable_idx = i;
>                 }
>         }
> +       if (!idx && prev_intercept_idx) {
> +               /*
> +                * We have to query the sleep length here otherwise we don't
> +                * know after wakeup if our guess was correct.
> +                */
> +               duration_ns = tick_nohz_get_sleep_length(&delta_tick);
> +               cpu_data->sleep_length_ns = duration_ns;

This is going to select the shallowest state anyway AFAICS, so is it
useful to check constraint_idx in this case?

> +       }
>
>         /*
>          * If there is a latency constraint, it may be necessary to select an
> --