Re: [PATCH] ACPI: Remove msleep() bloat from acpi_os_sleep()

[Rafael J. Wysocki]

On Fri, Aug 30, 2024 at 7:55 AM Len Brown <lenb@xxxxxxxxxx> wrote:
>
> On Thu, Aug 29, 2024 at 11:37 AM Anna-Maria Behnsen
> <anna-maria@xxxxxxxxxxxxx> wrote:
>
> > I created a patch for fsleep() - only complie tested - which should make
> > sure that the slack is maximum 25%. What do you think about it? Might it
> > be helpful?
>
> If the purpose of using msleep instead of usleep_range is to lower
> the cost of the timer sub-system....
>
> then I'm not sure that choosing to do an msleep instead of a usleep_range
> based on the timer duration makes any sense.
>
> The lighter overhead of the msleep is something that is more important
> when there are more timers.  More timers is not the same as longer timers.

My understanding is that when a new timer is added, it is not actually
known how many timers there are overall in use in the system, so it is
generally better to use a more lightweight variant in case there are
many of them.

However, the more lightweight variant is not suitable for short sleep
durations because it adds bloat of 2 jiffies (after the recent change
from Anna-Maria), so the idea is to start using msleep() at the point
when the bloat added by it starts to be comparable to the delta
between the usleep_range() arguments (used for short sleeps).

Now, because it is not known exactly what timer precision is required,
some assumptions need to be made and IMV it is reasonable to assume
that the actual sleep duration is expected to be somewhat greater than
requested, but it is also not expected to be much greater than
requested, so using a fraction of the requested sleep time as the
usleep_range() makes sense to me.

Of course, you can argue that in the ACPI case there are those
high-count loops and so more exact sleep durations are better, but
realistically this is mostly about system suspend/resume times and the
difference is not something that cannot be tolerated in that case IMV.
Also it would be better to avoid running those high-count loops in the
first place.

Overall, if my understanding is correct, I generally agree with
Anna-Maria's approach.