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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
> This rdtscp proposal is basically the latter, as a variant of the
> pvclock algorithm.  I'm mostly interested in it as an 
> implementation for
> vsyscall etc, rather than something that apps would use directly.

> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> I continue to think that it would be fundamentally wrong to use pCPU
> numbers here: Not only do you share information with the app that it
> shouldn't really care about, but you also push scalability 
> issues to it
> that the kernel is supposed to abstract out for apps.

While I have been hopeful that we can identify a solution that
can solve both problems (vsyscall+pvclock and pvrdtscp),
I have been concerned we might run into a fundamental conflict
since both of us may be attempting to use TSC_AUX
for somewhat different purposes.  Then in taking
a step back to think about this, I realized we may
be farther apart in our objectives than I first thought.
So I thought it would be a good idea to revisit
some assumptions.

I am assuming that rdtsc and rdtscp are always emulated;
but for some "high frequency timestamp apps" (HFTSAs),
trying to define a mechanism where rdtsc/rdtscp
are always correct AND, in certain constrained
environments, also fast (non-emulated).

Any userland pvclock algorithm still requires a rdtsc
(or rdtscp) instruction which -- EXCEPT in those
certain constrained environments -- is emulated.
But the whole point of pvclock is to be faster than
entering the hypervisor, right?

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?
Or am I missing another option altogether?

Dan

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