Re: kern/43997: Kernel timer discrepancies

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR kern/43997; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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.,
 ipsec_spi_ah_hmacsha512_preferred_new_timeout).
 
 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
 real time.
 
 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