> > I have yet to get a measurement of either syscall that
> > is better than 2.5x WORSE than emulating rdtsc. On
> > my dual-core Conroe (Intel E6850) with 64-bit Xen and
> > 32-bit dom0, I get approximately:
> > 
> > rdtsc native: 22ns
> > softtsc (rdtsc emulated): 360ns
>
> Trap-and-emulate in 360ns seems astoundingly good. Perhaps 
> too good to be true?
I measured with the patch you checked in as 20128.
I tried a couple of tests, first changing pv_soft_rdtsc
to always return a value with the 4 LSB of the return
value cleared, second with the 4 LSB of the return value
set. Both were properly reflected by a userland rdtsc.
So it looks like the correct emulation code is executing.
And get_s_time() always returns nanoseconds, correct?
So consecutive emulated rdtsc's should return values
that differ by the amount of nsec necessary to do
the emulation, right? I ran 2 million rdtsc's in
a loop and took the average so, ignoring loop
and load/store overhead, the 360ns appears to be
an accurate measurement.
A thousand cycles to trap, decode, call get_s_time,
and return seems astoundingly good? Probably it's
faster than a vmexit because there's so much less state
to save. But still it's 15x slower than a raw rdtsc.
If you have ideas on how to test the measurement further,
I'd be happy to give them a spin.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel