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: <CAJZ5v0ht7qZ_Da63c=RNvRovD=HYtT9A8S+-ng7qiKm3McdwEQ@mail.gmail.com>
Date: Mon, 18 Nov 2024 11:07:51 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Len Brown <lenb@...nel.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Anna-Maria Behnsen <anna-maria@...utronix.de>, 
	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, Nov 15, 2024 at 11:05 PM Len Brown <lenb@...nel.org> wrote:
>
> > Performance lower than the possible maximum doesn't necessarily count as "bad".
>
> System resume slower than 1 second will fail multiple product acceptance tests.
>
> That isn't good, it is bad :-)
>
> > > Re: if long sleeps then use msleep()
> > >
> > > ... because a jiffy based timer effectively forces coalescing, and is
> > > the lowest overhead.
> > >
> > > The problem with this logic is, as you mention, coalescing is a
> > > function of the distribution of timer expirations over time,it is not
> > > a function of the duration of those timers.
> >
> > I just think that high precision is not necessary for long timeouts.
> >
> > I also don't think that ASL programmers expect high precision in those cases.
>
> Precision isn't the question.
> The benefit of additional delay is the question.
>
> ie. if an ASL programmer asks for Sleep(100), they expect it to take
> no less than 100ms.
>
> msleep(100) takes 106ms -- effectively always.

For HZ=250.

> usleep-range(100,100) takes 100ms, effectively always.
>
> Is the additional 6ms delay really worth the saved overhead of using
> jiffies rather than a timer for an ACPI flow?

Or the other way around, is the better timer precision worth the
additional overhead?

AFAICS, the reason why you are pushing so hard for this is
suspend/resume delays due to loops of many iterations that sleep for a
short time in every iteration.

I'm kind of having a hard time with accepting the argument that the
kernel needs to be made to use more resources always in the ACPI path
to address just this one case.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ