linux-kernel - Re: [PATCH] ACPI: Remove msleep() bloat from acpi_os

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>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gE07+Nin5Weji20M-xOmjyWrixQU5PUnzZt=YWeH+-YA@mail.gmail.com>
Date: Fri, 30 Aug 2024 15:56:57 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Len Brown <lenb@...nel.org>
Cc: Anna-Maria Behnsen <anna-maria@...utronix.de>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, linux-acpi@...r.kernel.org, linux-pm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Frederic Weisbecker <frederic@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, Jonathan Corbet <corbet@....net>, 
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] ACPI: Remove msleep() bloat from acpi_os_sleep()

On Fri, Aug 30, 2024 at 7:55 AM Len Brown <lenb@...nel.org> wrote:
>
> On Thu, Aug 29, 2024 at 11:37 AM Anna-Maria Behnsen
> <anna-maria@...utronix.de> 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.