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