RE: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> I've run into a few problems from this patch:
> 
>    1. I'm seeing occasional messages on the console "hrtimer: 
> interrupt
>       too slow, forcing clock min delta to 9001953 ns" which indicates
>       that the kernel is noticing that timer operations are 
> taking too long.

Hmmm... that seems unlikely since it is highly probable that on
ANY machine, emulated TSC is faster than other highres timers,
for example, HPET. Perhaps it is a side effect of your assumptions
described in (2) below?

>    2. A domain can't turn on and off its own tsc emulation state.  I'm
>       working on vsyscall support for pvclock (done, aside from this
>       issue), so I need native tsc in usermode (or at least, one with
>       the same parameters in kernel and userspace).  I was 
> getting very
>       confused because I didn't expect emulation to *only* apply to
>       usermode; I was expecting it to be done uniformly to 
> both user and
>       kernel tscs, with appropriate adjustments to the vcpu_time_info
>       values.

Sorry, I should probably have said this explicitly in the patch
prologue, but there is no (easy/fast) way to turn on emulation
for userland and turn off emulation for the kernel, so rather
than requiring a change to the pvclock ABI, rdtsc emulation
returns a raw TSC value when the rdtsc was executed in kernel
mode and Xen system time (nsec) when the rdtsc was executed
in userland.

To ensure both correctness and maximum performance across
a wide range of conditions, WITHOUT destroying backward
compatiblity for the pvclock ABI, a decision tree similar
to the one I just posted for apps could be employed.

http://xen.markmail.org/message/uj4twbcsdw57z5zp

But this might rely on adding the same new Xen features
described in the parent to that post.

OTOH, if pvclock is executed sometimes in userland and
sometimes in kernel (e.g. depending on the setting of
a sysfs variable), it seems like some kind of decision
tree is required anyway.

>    3. The 's' debug key never seems to count any usermode rdtsc
>       instructions, even if I write a little program to explicitly
>       exercise them.  (Fix below)

Good catch.  Sorry, I tested that many times with an earlier version
of the patch, but didn't try debug-key with the final
version, after I went through and did some (apparently careless)
renaming.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel