[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
>>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 01.09.09 18:41 >>> >> >>> 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)? Sure, if the descriptor's DPL is set to 3. >> 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. These pvclock structs should be per vCPU, shouldn't they? The hypervisor ensures that the per-vCPU structure reflects the proper state on the pCPU that vCPU is currently running on. >> 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? I don't think it ever uses a pCPU number. If it does, just point me to where this is happening. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |