[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation

On 10/06/2009 04:19 PM, Dan Magenheimer wrote:
From: Jeremy Fitzhardinge [mailto:jeremy.fitzhardinge@xxxxxxxxxx]
With this in place, I can do a gettimeofday in about 100ns on a 2.4GHz
Q6600.  I'm sure this could be tuned a bit more, but it is
already much better than a syscall.
To evaluate the goodness of this, we really need a full
set of measurements for:

a) cost of rdtsc (and rdtscp if different)
b) cost of vsyscall+pvclock
c) cost of rdtsc emulated
d) cost of a hypercall that returns "hypervisor system time"

On a E6850 (3Ghz but let's use cycles), I measured;

a == 72 cycles
c == 1080 cycles
d == 780 cycles

It may be partly apples and oranges, but it looks
like a good guess for b on my machine is

b == 240 cycles

Two rdtscps should suffice (and I think they are much faster on modern machines).

Not bad, but is there any additional context switch
cost to support it?

rdtscp requires an additional msr read/write on heavyweight host context switches. Should be negligible compared to the savings.

From: Avi Kivity [mailto:avi@xxxxxxxxxx]
Instead of using vgetcpu() and rdtsc() independently, you can
use rdtscp
to read both atomically.  This removes the need for the
preempt notifier.
Xen does not currently expose rdtscp and so does not emulate
(or context switch) TSC_AUX.  Context switching TSC_AUX
is certainly possible, but will likely be expensive.
If the primary reason for vsyscall+pvclock is to maximize
performance for gettimeofday/clock_gettime, this cost
would need to be added to the mix.

It will cost ~100 cycles on heavyweight host context switch (guest-to-guest).

preempt notifiers are per-thread, not global, and will upset
the cycle
counters.  I'd drop them and use rdtscp instead (and give up if the
processor doesn't support it).
Even if rdtscp is used, in the Intel processor lineup
only the very latest (Nehalem) supports rdtscp, so
"give up" doesn't seem like a very good option, at least
in the near future.

Why not? we still fall back to the guest kernel. By the time guest kernels with rdtscp support are in the field, these machines will be quiet old.

error compiling committee.c: too many arguments to function

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.