Re: [PATCH v1 2/9] cpuidle: teo: Reorder candidate state index checks
From: Christian Loehle
Date: Wed Jan 15 2025 - 09:47:02 EST
On 1/13/25 18:36, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
>
> Since constraint_idx may be 0, the candidate state index may change to 0
> after assigning constraint_idx to it, so first check if it is greater
> than constraint_idx (and update it if so) and then check it against 0.
So the reason I've left this where it was is because the prev_intercept_idx
was supposed to query the sleep length if we're in an majority-intercept
period and then it makes sense to query the sleep length (to detect such
a period being over).
A constraint_idx == 0 scenario doesn't need the intercept-machinery to
work at all, why are we querying the sleep length then?
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> ---
>
> This is a rebased variant of
>
> https://lore.kernel.org/linux-pm/8476650.T7Z3S40VBb@xxxxxxxxxxxxx/
>
> ---
> drivers/cpuidle/governors/teo.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> --- a/drivers/cpuidle/governors/teo.c
> +++ b/drivers/cpuidle/governors/teo.c
> @@ -428,6 +428,14 @@
> break;
> }
> }
> +
> + /*
> + * If there is a latency constraint, it may be necessary to select an
> + * idle state shallower than the current candidate one.
> + */
> + if (idx > constraint_idx)
> + idx = constraint_idx;
> +
> if (!idx && prev_intercept_idx) {
> /*
> * We have to query the sleep length here otherwise we don't
> @@ -439,13 +447,6 @@
> }
>
> /*
> - * If there is a latency constraint, it may be necessary to select an
> - * idle state shallower than the current candidate one.
> - */
> - if (idx > constraint_idx)
> - idx = constraint_idx;
> -
> - /*
We could leave this here and just do goto end;?