Re: write_tsc in a PV domain?

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 08/27/09 01:48, Alan Cox wrote:
>> as part of its ABI.  It is not a general tsc.  You can't meaningfully
>> execute "rdtsc" without also being (indirectly) aware of what pcpu its
>> running on and applying the appropriate corrections to turn it into
>> system monotonic time.  Executing rdtsc willy-nilly gets you useless
>> results; fortunately no PV Xen kernel does that.
>>     
> Actually for user space this isn't at all true. You can use rdtsc
> directly and sample the data for things like profiling then correct for
> things like spikes and skews from processor switches by filtering.
>   

If an app is sophisticated to do this correctly then it doesn't need any
special assistance from a hypervisor to make the tsc well-behaved.  It
should continue to work even in a Xen guest where both the process can
skip between VCPUs and the VCPUs can skip between PCPUs.

>> No, write_tsc is meaningless, and anyone trying to execute it is not
>> even wrong.
>>     
> Writing to the tsc is perfectly reasonable providing the tsc is an
> advertised feature. Being able to use the tsc becomes much more relevant
> with newer processors which have sane tsc implementations in the
> architecture however.
>   

Apparently on some large servers the tsc is only synced and sane within
a NUMA node, and not globally across all processors, so any app which
assumed sane tsc behaviour would break when the hardware gets scaled up.

But in this case I'm talking specifically about a Xen PV guest, where
the tsc is claimed for use by the Xen clocksource ABI.

> Unfortunately if you hide the tsc and hide the tsc flag in the cpu info
> lots of stuff doesn't run due to crap coding 8(
>   

And you can't actually hide the TSC flag in cpuid without virtualization
extensions.

    J