Re: Accurate timers in rumpkernels on Xen / minios
- From: George Dunlap <dunlapg@xxxxxxxxx>
- To: pooka@xxxxxx
- Date: Fri, 27 May 2016 15:04:45 +0100
On Fri, May 27, 2016 at 1:17 PM, Antti Kantee <pooka@xxxxxx> wrote:
Well, try this hacky patch. It's not correct by any stretches of
imagination, nor am I promising to accept something like it into Rumprun,
but if you can repeat my results, at least we've narrowed down the problem.
In my testing the clock_gettime-to-clock_gettime delay for a 1ns sleep on
KVM is ~8us with this patch.
(btw, the init code might not in correct order as indicated by the comment,
try to hack around it somehow if that happens)
Hmm, it didn't work as advertised; the code seems to have run, but the
same issue remains:
---
[snip]
NetBSD 7.99.21 (RUMP-ROAST)
total memory = 30246 KB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
cpu0 at thinair0: rump virtual cpu
root file system type: rumpfs
kern.module.path=/stand/amd64/7.99.21/modules
mainbus0 (root)
timecounter: Timecounter "bmktc" frequency 1000000000 Hz quality 100
establishing hacky clock syscalls
mounted tmpfs on /tmp
=== calling "worker-xen.img" main() ===
argc: 4
Mapped memory at 0xb98000
START JSON
{ "Now":1000796436, "Mops":0, "MaxDelta":0 }
{ "Now":2026761676, "Mops":60, "MaxDelta":10064020 }
{ "Now":3047938959, "Mops":118, "MaxDelta":10050889 }
[etc]
---
That looks like it should have happened after syscalls were
established, but hard for me to say.
I think I may have to come back to this another day. In the mean
time, is there a simple way to change the clock HZ? These VMs are
never going to be very idle while they're running; even setting it to
1000 should help, and probably even 10000 wouldn't hurt performance
too much I don't think (unless a lot more is done on the clock ticks
than I know about).
-George
Other related posts:
