[<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