WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Tue, 22 Sep 2009 12:36:18 -0700 (PDT)
Cc: kurt.hackel@xxxxxxxxxx, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Tue, 22 Sep 2009 12:36:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AB81289.8040604@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> 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

<Prev in Thread] Current Thread [Next in Thread>