On 27/05/16 14:04, George Dunlap wrote:
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:
Then I don't know. It made a difference for me. There's something to
be said about the scientific process of posting the actual code to allow
others to repeat the experiment. Here's mine:
=== snip ===
#include <sys/types.h>
#include <stdio.h>
#include <time.h>
#include <unistd.h>
int
main()
{
struct timespec ts, ts1, ts2;
ts.tv_sec = 0;
ts.tv_nsec = 1000;
clock_gettime(CLOCK_REALTIME, &ts1);
nanosleep(&ts, NULL);
clock_gettime(CLOCK_REALTIME, &ts2);
timespecsub(&ts2, &ts1, &ts);
printf("%ld\n", ts.tv_nsec);
}
=== snip ===
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).
I can't think of a way to set it from the command line, but you can just
edit -DHZ=foo into one of the CPPFLAGS defines in
src-netbsd/sys/rump/Makefile.rump ... or, while you're editing the
sources, you might as well change it in src-netbsd/sys/conf/param.c
I don't know if some calculations will flow over or under if you set it
ridiculously high (I know they will if you set it ridiculously low), so
start with a safe number. alpha uses 1024, so at least that works.
There shouldn't be a whole lot of stuff going on. The clock interrupt
thread wakes up once per hz, but it doesn't do much except check if
callouts need to run, and callouts are usually scheduled in terms of
seconds. But, only one way to find out.
If you decide you want to set it all the time, can add a flag to
buildrump.sh which allows manual additions to the imacros file, in which
case you could do something like:
./build-rr.sh xen -- -m '#define HZ zillion'
... at least unless I meanwhile remember it's settable some other way.
It's a bit strange that NetBSD clips the sleep time to the clock HZ --
that seems like it's probably an artifact of a bygone age.
"patches welcome", and all that.
