[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/43997: Kernel timer discrepancies
The following reply was made to PR kern/43997; it has been noted by GNATS.
From: Andreas Gustafsson <gson%gson.org@localhost>
Subject: Re: kern/43997: Kernel timer discrepancies
Date: Sat, 29 Sep 2018 16:26:36 +0300
Almost eight years ago, Paul Goyette wrote:
> The routines sleep(3), usleep(3), and nanosleep(2) wake-up based on the
> occurrence of clock ticks. However, the timer interrupt routine determines
> the actual absolute time. Normally this isn't an issue, but on systems
> that can "miss" interrupts it can result in significant discrepancies.
> One such system is qemu, frequently used for providing a system test-bed
> environment. On (at least) amd64 architecture, qemu cannot simulate clock
> interrupts at 100Hz. Therefore, a simple "date ; sleep 5; date" command
> actually requires 10 seconds to complete!
This is still an issue. Some observations:
1. As a work-around, attempts are made to skip certain tests under
qemu, but the method used to detect qemu does not work for sparc
guests, so on sparc, these tests are still run and fail (e.g.,
2. There are three parties to the problem: the host, qemu, and the
guest. Paul's original report frames it as a guest problem (the guest
not dealing with lost clock interrupts), but IMO the real bug is that
the interrupts are lost in the first place, and the root cause of that
lies not with the guest nor with qemu, but with the host.
Specifically, it's a problem of host timer granularity: on a NetBSD
host with the default hz=100, calling poll() with a timeout of 5 ms
(as qemu does) results in a sleep taking anywhere between 10 and 20
ms, and repeated calls will return at regular 20 ms intervals. It is
hardly surprising that qemu can't schedule guest clock interrupts at
10 ms intervals when the host can't wake qemu up at intervals less
than 20 ms.
IMO, the correct way to fix this is for NetBSD to go tickless, as
Linux and FreeBSD already have. Until that happens, possible
work-arounds are to increase the hz parameter on the host, or to
host qemu on an OS other than NetBSD.
3. It should also be possible to work around the issue by making the
guest have its own notion of time, independent of the host time and
instead based on a count of emulated guest instructions. This would
also have other advantages: it would make test execution more
deterministic, and it would allow speeding up the tests by "warping"
the virtual guest time instantly to the next clock tick whenever the
guest enters the idle loop, so that guest idle time would consume no
Qemu claims to already support this through the "--icount" option
and its "sleep" keyword, but sadly, it doesn't actually work. See
https://bugs.launchpad.net/qemu/+bug/1774677 for the bug report.
Andreas Gustafsson, gson%gson.org@localhost
Main Index |
Thread Index |