Re: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Jeremy Fitzhardinge <jeremy@xxxxxxxx> 21.09.09 20:36 >>>
>What's the full algorithm for detecting this feature?  Usermode has to
>establish:
>
>   1. It is running under Xen (or not, if you expect this to be
>      implemented on multiple hypervisors)
>   2. rdtscp is available
>   3. the ABI is actually being implemented, ie:
>         1. the tsc_aux value actually has the correct meaning
>         2. it has a working mechanism for getting the tsc scaling
>            parameters

This sub-2 can certainly be assumed to imply the respective sub-1.

>         3. (accommodate ways to evolve the ABI in a back-compatible way)
>
>before it can do anything else.

>The obvious thing to do is to pack a version number and pcpu number into
>TSC_AUX.  Usermode would maintain an array of pv_clock parameters, one
>for each pcpu.  If the version number matches, then it uses the
>parameters it has; if not it fetches new parameters and repeats the
>rdtscp.  There's no need to worry about either thread or vcpu context
>switches because you get the (tsc,params) tuple atomically, which is the
>tricky bit without rdtscp.
>
>(The version number would be truncated wrt the normal pvclock version
>number, but it just needs to be large enough to avoid aliasing from
>wrapping; I'm assuming something like 24 bits version and 8 bits cpu
>number.)

I continue to think that it would be fundamentally wrong to use pCPU
numbers here: Not only do you share information with the app that it
shouldn't really care about, but you also push scalability issues to it
that the kernel is supposed to abstract out for apps.

In particular,
- the interface must not imply an upper bound for the number of
pCPU-s (i.e. a fixed 8-/24-bit separation won't work, but reducing the
version to significantly below 24 bits may cause issues),
- the app must not imply the number of pCPU-s is bounded in any way
(since, due to migration or CPU hotplug, it may grow).

While both can be addressed, this really isn't something an app should
(have to) care about.

Jan


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