On Mon, Nov 18, 2024 at 6:03 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> if (ms >= 12 * MSEC_PER_SEC / HZ) {
> msleep(ms);
> } else {
> u64 us = ms * USEC_PER_MSEC;
>
> usleep_range(us, us / 8);
> }
The purpose of delaying a timer via timer slack is to afford the
opportunity to coalesce timers, when the precision wasn't actually
necessary.
I agree that precision is not necessary here -- we are talking about
acpi_os_sleep(), which has a granularity of 1ms.
So the question becomes how much coalescing do we get for how much delay?
In the suspend/resume flows that sparked this discussion, the answer
is zero --- and so for that case, zero timer slack is justified.
I acknowledge that you refuse to apply my patch.
However, if you are going to add slack, I would like it to be clear
why users tasks, which may invoke HR timers at a dizzying rate, are
subject to a flat 50us timerslack_ns, while the entire ACPI
sub-system, which invokes a single timer, would see a 650usec delay
added for 5,000 usec sleep.
--
Len Brown, Intel
