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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 01.09.09 17:56 >>>
> >Can you think of any trick (that doesn't require the cost of a
> >trap/hypercall) to allow an app to determine what pcpu
> >it is running on?
> 
> 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.

Can you explain more?  Will this work for a userland
process to get its current pcpu (not vcpu)?

> I am, however, always a little bit concerned when it comes to exposing
> information that shouldn't really be exposed, due to the 
> possibility of
> overlooking potential misuses. In the specific case here, I 
> can't see at all
> why you'd the pCPU number exposed

There is one pvclock "struct" for each pcpu.  We want
an app to "see" the right one.  If that's not possible,
we want the app to see the whole array of them and be
able to properly index into the array.

If possible, I'd like to see if we can identify a solution
at all, and then discard it if the issues are too difficult
to overcome.

> after all the kernel can do what
> you want apps to do without having that information.

In the current Linux 2.6.30 implementation of pvclock
it can do it, but it can't do it fast.  In versions
of the kernel prior to 2.2.28(?), it can't do it at
all, correct?

Thanks,
Dan

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