Re: Fixing timekeeping for rumprun/hw
- From: Martin Lucina <martin@xxxxxxxxxx>
- To: rumpkernel-users@xxxxxxxxxxxxx
- Date: Mon, 22 Jun 2015 11:38:26 +0200
On Saturday, 20.06.2015 at 12:19, Antti Kantee wrote:
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.
Unfortunately timekeeping is all about tradeoffs. If we want to use the TSC
at all on non-virtualized x86, then we have no other option than
calibrating it against another known-good timesource. AFAICT Linux gets
around the delay by virtue of having the clocksource framework, so the
calibration is essentially done in the background and the system switches
to TSC (or HPET, or LAPIC, or whatever) once it is done.
However, I don't have the time right now to implement a full clocksource
framework, nor do I think we really need one right now.
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.
Any improvement is better than what we have now.
As a first cut, a PIT-only implementation for *non-virtualized* x86 with a
maximum accuracy of 100 Hz is probably fine. It is possible to dynamically
reprogram the PIT and lower the tick rate when we know that the system will
be idle for longer periods of time, so I'll look into that.
At the same time, I'll work to make sure that the code can take advantage
of a KVM pvclock when one is available. That should give us the best of
both worlds with hopefully not too much complexity.
Anyhow, I need to try some approaches and measure the results, we can then
iterate on that once I have something that works.
Other related posts:
