RE: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> On 09/22/09 12:36, Dan Magenheimer wrote:
> > Are you (Jeremy) still assuming that rdtsc/rdtscp are NOT
> > emulated?  Or are you trying to define a vsyscall+pvclock
> > mechanism for the same constrained environments
> > so that HFTSAs have a choice of using clock_gettime
> > instead of pvrdtsc, either of which will be fast?  
> 
> Yes, I'm assuming they're not emulated.

OK, that's what I feared.

I don't know how this decision will be made, but any pvclock
and pvrdtsc design work is very dependent on the decision.

> If you're emulating them
> there's no reason to add any extra complexity to usermode by 
> adding any
> other ABI: rdtsc can be rdtsc and rdtscp can be rdtscp with no
> Xen/ABI-imposed constraints on TSC_AUX.

The reason is to improve performance while preserving
correctness for applications that need to do tens-to-hundreds
of thousands "timestamp reads" without changing the underlying
OS.  Whether this is a GOOD reason is subject to interpretation,
but it is a reason.

> Once you're talking about layering another ABI onto the tsc, then
> there's no need to consider emulation because you can do all the
> necessary correction to get a canonical timestamp without it.

But only at the cost of losing correctness for (whether
you consider them fundamentally broken or not) apps that
depend on the rdtsc instruction to deliver the
architecturally-defined functionality and may silently
fail or corrupt data if rdtsc silently doesn't behave as
defined.

Dan

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