On Fri, May 27, 2016 at 1:17 PM, Antti Kantee <[email protected]> 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
