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: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Tue, 1 Sep 2009 15:08:26 -0700 (PDT)
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 01 Sep 2009 15:10:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C6C34FE4.13AC4%keir.fraser@xxxxxxxxxxxxx>
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
> > Just like what is being used to allow apps to get the CPU 
> number on native
> > kernels (or the vCPU one on Xen-ified ones): Have a GDT 
> entry the limit of
> > which is the number you want, and have the app use the lsl 
> instruction to
> > get at it.
> 
> Yes, that's true. Xen could provide such a segment descriptor 
> in its private
> area of the GDT. The issue then would be that, in a compound pvclock
> operation spanning multiple machine instructions, the pCPU 
> number revealed
> by the LSL instruction can be stale by the time it is used 
> later in the
> compound operation.

The algorithm could check the pCPU number before and after
reading the pvclock data and doing the rdtsc, and if they
don't match, start again.  (Doesn't the pvclock algorithm
already do that with some versioning number in the pvclock
data itself to ensure that the rest of the data didn't
change while it was being read?)

I'm clueless about GDTs and the LSL instrution so would
need some help prototyping this.

Dan

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

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