RE: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 02.09.09 00:08 >>>
>> > 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?)

No, that won't do - the underlying pCPU may change multiple times
during that process.

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

As said in another reply, such a descriptor already exists
(PER_CPU_GDT_ENTRY).

But as also already said, I doubt you really need this.


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