[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <90818e23-0bdb-40ad-b2f9-5117c7d8045e@linux.intel.com>
Date: Mon, 18 Nov 2024 06:35:17 -0800
From: Arjan van de Ven <arjan@...ux.intel.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>
Cc: anna-maria@...utronix.de, tglx@...utronix.de, peterz@...radead.org,
frederic@...nel.org, corbet@....net, akpm@...ux-foundation.org,
linux-acpi@...r.kernel.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, Len Brown <len.brown@...el.com>,
Todd Brandt <todd.e.brandt@...el.com>
Subject: Re: [PATCH v2] ACPI: Replace msleep() with usleep_range() in
acpi_os_sleep().
> And the argument seems to be that it is better to always use more
> resources in a given path (ACPI sleep in this particular case) than to
> be somewhat inaccurate which is visible in some cases.
>
> This would mean that hrtimers should always be used everywhere, but they aren't.
more or less rule of thumb is that regular timers are optimized for not firing case
(e.g. timeouts that get deleted when the actual event happens) while hrtimers
are optimized for the case where the timer is expected to fire.
(I'm with you on the slack argument, some amount of slack, even if it is only a usec or two,
is very helpful)
Powered by blists - more mailing lists