Messages in this thread |  | | Date | Wed, 15 Jan 2025 19:43:11 +0000 | | Subject | Re: [PATCH v1 5/9] cpuidle: teo: Clarify two code comments | | From | Christian Loehle <> |
| |
On 1/13/25 18:41, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.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@intel.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@arm.com>
|  |