From nobody Mon Nov 25 08:19:38 2024 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C733414F9D9; Fri, 15 Nov 2024 23:11:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.14 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731712293; cv=none; b=QLjQblsfk4EGfQisYbQPC8l3rkBW5Ad5cXMG+zLJ2vWFiYMMLOLxAFolnZv5o1OeaB1KjNeQ/E4/KzOvuLO41KQaF1VzME9FwGe4H6iDivNmZmP6RblbnouXaKPGKluuUoE1O6p0i123hU/T8CK5mLn0iLUcGapoWy1sWqkVnRs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731712293; c=relaxed/simple; bh=X2uV+UlO+oeyFtpTc37ncoYBy0ncSnOv9AW0Udtr1Sw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=RGdRHHiCFkqw7f0hNGIYhgefgAJF4eeDKawl6R0NAcyhe26ZHQeRpv9a4KbmkWqnPrGuNYahIDV0bpPRdrD1wvzfvH7QF2lSIX3toMexfoZGFS1Oq3JdEvLz9xTl3OIEZ1d7Gr4rwi04WcHo+UgStmSCQrEZgN/IFqjWnBfhCUI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=kernel.org; spf=fail smtp.mailfrom=kernel.org; arc=none smtp.client-ip=198.175.65.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=kernel.org X-CSE-ConnectionGUID: fS/R+NUcSEOLb7sKlcNqOA== X-CSE-MsgGUID: 3wzlmOXjTQSDY9VKTxIn9Q== X-IronPort-AV: E=McAfee;i="6700,10204,11257"; a="35499991" X-IronPort-AV: E=Sophos;i="6.12,158,1728975600"; d="scan'208";a="35499991" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Nov 2024 15:11:31 -0800 X-CSE-ConnectionGUID: 1o93KFeCQwyDEy9ptvPpIA== X-CSE-MsgGUID: VXddfeRZQx2L/9zWnIh/Cg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,158,1728975600"; d="scan'208";a="88694780" Received: from gargmani-mobl1.amr.corp.intel.com (HELO lenb-Thinkpad-T16-Gen-3.mynetworksettings.com) ([10.124.221.226]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Nov 2024 15:11:28 -0800 From: Len Brown 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 , Arjan van de Ven , Todd Brandt Subject: [PATCH v2] ACPI: Replace msleep() with usleep_range() in acpi_os_sleep(). Date: Fri, 15 Nov 2024 18:11:13 -0500 Message-ID: X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Reply-To: Len Brown Organization: Intel Open Source Technology Center Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Len Brown 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=3D216263 Signed-off-by: Len Brown Suggested-by: Arjan van de Ven Tested-by: Todd Brandt --- 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, a= cpi_osd_handler handler) =20 void acpi_os_sleep(u64 ms) { - msleep(ms); + u64 us =3D ms * USEC_PER_MSEC; + + usleep_range(us, us); } =20 void acpi_os_stall(u32 us) --=20 2.43.0