[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
>>> Jeremy Fitzhardinge <jeremy@xxxxxxxx> 03.09.09 00:05 >>> > 1. Add a hypercall to set the desired location of the clock > correction info rather than putting it in the shared-info area > (akin to vcpu placement). KVM already has this; they write the > address to a magic MSR. But this is already subject to placement, as it's part of the vcpu_info structure. While of course you don't want to make the whole vcpu_info visible to guests, it would seem awkward to further segregate the shared_info pieces. I'd rather consider adding a second (optional) copy of it, since the updating of this is rather little overhead in Xen, but using this in the kernel time handling code would eliminate the potential for accessing all the vcpu_info fields using percpu_read(). > 2. Pack all the clock structures into a single page, indexed by vcpu > number That adds a scalability issue, albeit a relatively light one: You shouldn't anymore assume there's a limit on the number of vCPU-s. > 3. Map that RO into userspace via fixmap, like the vsyscall page itself > 4. Use the lsl trick to get the current vcpu to index into the array, > then compute a time value using tsc with corrections; iterate if > version stamp changes under our feet. > 5. On context switch, the kernel would increment the version of the > *old* vcpu clock structure, so that when the usermode code > re-checks the version at the end of its time calculation, it can > tell that it has a stale vcpu and it needs to iterate with a new > vcpu+clock structure I don't think you can re-use the hypervisor updated version field here, unless you add a protocol on how the two updaters avoid collision. struct vcpu_time_info has a padding field, which might be designated as guest-kernel-version. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |