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] RE: rdtsc: correctness vs performance on Xen (and KVM?)

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Thu, 3 Sep 2009 07:22:12 -0700 (PDT)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 03 Sep 2009 07:22:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A9EEC3D.4070402@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
> I was imagining:
> 
>    1. Add a hypercall to set the desired location of the clock
>       correction info rather than putting it in the shared-info area
>       (akin to vcpu placement).  KVM already has this; they write the
>       address to a magic MSR.
>    2. Pack all the clock structures into a single page, 
> indexed by vcpu
>       number
>    3. Map that RO into userspace via fixmap, like the 
> vsyscall page itself
>    4. Use the lsl trick to get the current vcpu to index into 
> the array,
>       then compute a time value using tsc with corrections; iterate if
>       version stamp changes under our feet.
>    5. On context switch, the kernel would increment the version of the
>       *old* vcpu clock structure, so that when the usermode code
>       re-checks the version at the end of its time calculation, it can
>       tell that it has a stale vcpu and it needs to iterate with a new
>       vcpu+clock structure

It would be nice to see a prototyped version of this so
it could be confirmed that it works, the kernel impact
can be evaluated, performance can be measured, and,
if all looks good, distros can start putting it into
their kernels.

Also, it would be nice if there is some way for apps to
determine if it is present and working, e.g.

if (clock_gettime_performance_doesnt_suck)
   t = clock_gettime();
else {
   t= rdtsc();
   apply_post_processing(t);
}

as apparently sysctl.vsyscall64==1 is not sufficient.

In fact, if there can be agreement as to how this
determination can be done (sysctl.fastpvclock==1??)
apps could start getting ready.

Dan

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

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