[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7eb5b339-c4f1-4eaa-b9c1-4c775c99efaf@arm.com>
Date: Wed, 15 Jan 2025 19:43:11 +0000
From: Christian Loehle <christian.loehle@....com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux PM <linux-pm@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>
Subject: Re: [PATCH v1 5/9] cpuidle: teo: Clarify two code comments
On 1/13/25 18:41, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> Rewrite two code comments suposed to explain its behavior that are too
s/suposed/supposed
> concise or not sufficiently clear.
>
> No functional impact.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> ---
> drivers/cpuidle/governors/teo.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> --- a/drivers/cpuidle/governors/teo.c
> +++ b/drivers/cpuidle/governors/teo.c
> @@ -154,9 +154,10 @@
>
> if (cpu_data->time_span_ns >= cpu_data->sleep_length_ns) {
> /*
> - * One of the safety nets has triggered or the wakeup was close
> - * enough to the closest timer event expected at the idle state
> - * selection time to be discarded.
> + * This causes the wakeup to be counted as a hit regardless of
regardless of twice.
> + * regardless of the real idle duration which doesn't need to be
> + * computed because the wakeup has been close enough to an
> + * anticipated timer.
> */
> measured_ns = U64_MAX;
> } else {
> @@ -302,8 +303,13 @@
>
> cpu_data->time_span_ns = local_clock();
> /*
> - * Set the expected sleep length to infinity in case of an early
> - * return.
> + * Set the sleep length to infitity in case the invocation of
s/infitity/infinity
> + * tick_nohz_get_sleep_length() below is skipped, in which case it won't
> + * be known whether or not the subsequent wakeup is caused by a timer.
> + * It is generally fine to count the wakeup as an intercept then, except
> + * for the cases when the CPU is mostly woken up by timers and there may
> + * be opportunities to ask for a deeper idle state when no imminent
> + * timers are scheduled which may be missed.
With the above typo fixes.
Reviewed-by: Christian Loehle <christian.loehle@....com>
Powered by blists - more mailing lists