mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: rafael@kernel.org
Cc: anna-maria@linutronix.de, tglx@linutronix.de,
	peterz@infradead.org, frederic@kernel.org, corbet@lwn.net,
	akpm@linux-foundation.org, linux-acpi@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Len Brown <len.brown@intel.com>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Todd Brandt <todd.e.brandt@intel.com>
Subject: [PATCH v2] ACPI: Replace msleep() with usleep_range() in acpi_os_sleep().
Date: Fri, 15 Nov 2024 18:11:13 -0500	[thread overview]
Message-ID: <c7db7e804c453629c116d508558eaf46477a2d73.1731708405.git.len.brown@intel.com> (raw)

From: Len Brown <len.brown@intel.com>

Replace msleep() with usleep_range() in acpi_os_sleep().

This has a significant user-visible performance benefit
on some ACPI flows on some systems.  eg. Kernel resume
time of a Dell XPS-13-9300 drops from 1943ms to 1127ms (42%).

usleep_range(min, min) is used because there is scant
opportunity for timer coalescing during ACPI flows
related to system suspend, resume (or initialization).

ie. During these flows usleep_range(min, max) is observed to
be effectvely be the same as usleep_range(max, max).

Similarly, msleep() for long sleeps is not considered because
these flows almost never have opportunities to coalesce
with other activity on jiffie boundaries, leaving no
measurably benefit to rounding up to jiffie boundaries.

Background:

acpi_os_sleep() supports the ACPI AML Sleep(msec) operator,
and it must not return before the requested number of msec.

Until Linux-3.13, this contract was sometimes violated by using
schedule_timeout_interruptible(j), which could return early.

Since Linux-3.13, acpi_os_sleep() uses msleep(),
which doesn't return early, but is still subject
to long delays due to the low resolution of the jiffie clock.

Linux-6.12 removed a stray jiffie from msleep: commit 4381b895f544
("timers: Remove historical extra jiffie for timeout in msleep()")
The 4ms savings is material for some durations,
but msleep is still generally too course. eg msleep(5)
on a 250HZ system still takes 11.9ms.

System resume performance of a Dell XPS 13 9300:

Linux-6.11:
msleep HZ 250	2460 ms

Linux-6.12:
msleep HZ 250	1943 ms
msleep HZ 1000	1233 ms
usleep HZ 250	1127 ms
usleep HZ 1000	1130 ms

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=216263
Signed-off-by: Len Brown <len.brown@intel.com>
Suggested-by: Arjan van de Ven <arjan@linux.intel.com>
Tested-by: Todd Brandt <todd.e.brandt@intel.com>
---
 drivers/acpi/osl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 70af3fbbebe5..daf87e33b8ea 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -607,7 +607,9 @@ acpi_status acpi_os_remove_interrupt_handler(u32 gsi, acpi_osd_handler handler)
 
 void acpi_os_sleep(u64 ms)
 {
-	msleep(ms);
+	u64 us = ms * USEC_PER_MSEC;
+
+	usleep_range(us, us);
 }
 
 void acpi_os_stall(u32 us)
-- 
2.43.0


             reply	other threads:[~2024-11-15 23:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-15 23:11 Len Brown [this message]
2024-11-18 11:03 ` Rafael J. Wysocki
2024-11-18 11:38   ` Hans de Goede
2024-11-18 12:02     ` Rafael J. Wysocki
2024-11-18 12:10       ` Hans de Goede
2024-11-18 12:22         ` Rafael J. Wysocki
2024-11-20  9:01       ` Pierre Gondois
2024-11-20 12:06         ` Dietmar Eggemann
2024-11-20 12:59           ` Pierre Gondois
2024-11-18 14:35   ` Arjan van de Ven
2024-11-19 13:42     ` Rafael J. Wysocki
2024-11-19 15:08       ` Arjan van de Ven
2024-11-20 18:03         ` Rafael J. Wysocki
2024-11-20 18:37           ` Arjan van de Ven
2024-11-20 18:49             ` Rafael J. Wysocki
2024-11-20 18:54               ` Len Brown
2024-11-20 19:27                 ` Rafael J. Wysocki
2024-11-20 19:18               ` Arjan van de Ven
2024-11-20 19:41                 ` Rafael J. Wysocki
2024-11-21 10:33                   ` Len Brown
2024-11-20 18:35   ` Len Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c7db7e804c453629c116d508558eaf46477a2d73.1731708405.git.len.brown@intel.com \
    --to=lenb@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=anna-maria@linutronix.de \
    --cc=arjan@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=frederic@kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=todd.e.brandt@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®