[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.