Re: Fixing timekeeping for rumprun/hw
- From: Antti Kantee <pooka@xxxxxx>
- To: rumpkernel-users@xxxxxxxxxxxxx
- Date: Sat, 20 Jun 2015 12:19:46 +0000
On 19/06/15 16:42, Martin Lucina wrote:
The interesting parts of the code are:
In bmk_x86_initclocks(), I compute the TSC frequency by calibrating it
against a fixed 100000 us delay using the PIT:
initial_tsc = rdtsc();
i8254_delay(100000);
tsc_freq = (rdtsc() - initial_tsc) * 10;
A 0.1s delay in bootstrap is ginormous, considering that a hardwareless
rump kernel initializes in much less than 0.01s on anything modern and
non-ARM. I'd work very hard to avoid a >10x unconditional guest
bootstrap code execution time increase.
3) Give up on TSC and just count PIT ticks at 100 Hz. This results in less
precision (but we don't care too much as the rump kernel HZ runs at 100
anyway), however relies on the PIT interrupt always being enabled which is
not terribly efficient (esp. in a virtualized environment). It does,
however, have the advantage of not depending on TSC which means it will run
on a 486-class processor. This may be useful for some embedded use cases.
I'd steer clear of that. It's the wrong direction to go in, plus the
logic "events happen at HZ, therefore we don't care about clock
inaccuracy" is unsound.
Generally speaking and not exactly related to timekeeping, for rumprun
we should lower HZ as low as it can go. There are some silly timeout
calculations in the NetBSD code where hz/x is calculated to sleep a
fraction of a second, and 0 means "sleep eternally". IIRC 16 is a safe
limit. if someone wants to go over the code and fix them -- assuming
they already haven't been fixed -- I think we could go below 10 without
affecting e.g. TCP timers too much. Since we don't have to care about
HZ affecting system responsiveness, things are a lot simpler.
Did you look at FreeBSD? I think they support tickless, so you might
get some hints from reading that code.
Thanks for working on this!
Other related posts:
