RE: [Xen-devel] [RFC] Correct/fast timestamping in apps under Xen [1 of 4]: Reliable TSC

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Excellent!  This is an extremely important piece
of the puzzle now filled in.

Just for completeness, on your machine, what is
the measurement for raw rdtsc?

(And if anybody believes this is the ONLY piece
of the puzzle that is necessary, I would be happy
to expand further.)

> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
> On 10/09/09 02:34, Tim Deegan wrote:
> > Your plans for usermode<-->hypervisor direct TSC 
> integration seem to me
> > to be an unpleasant hack.  I understand that you have good business
> > reasons for wanting it (even if you're not allowed to tell 
> us explicitly
> > what they are) and we've seen the justifications enough 
> times that we
> > don't need to cover them again here, but it's still a hack.
> >
> > I'm unhappy with the idea of kicking around the Xen timekeeping code
> > (and introducing the usual bug-tail) to support introducing 
> a usermode
> > TSC.  If there is to be a new mode for this, it should 
> default to the
> > current (works for everyone except the engineering team of a
> > not-to-be-named enterprise application) behaviour.
> 
> I'm seeing an approx 12x performance improvement with 
> gettimeofday() and
> clock_gettime() on systems with my vsyscall support patches
> (~1200ns/call -> ~100ns[*]).  I think that should go a long 
> way towards
> mitigating the performance concerns using standard APIs.  
> 
> There's probably some scope for improving those numbers on 
> systems with
> better-than-baseline tsc support (ie rdtscp and/or guaranteed synced
> tscs), but I think its enough to get started with, especially 
> given the
> broad applicability and relatively simple engineering.
> 
> [*] With native tsc; emulated tsc makes that 1700 -> 500, or 
> only ~3.3x
> improvement.
> 
>     J

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