Re: [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)

[Jeremy Fitzhardinge <jeremy@goop.org>]

On 09/28/09 16:36, Dan Magenheimer wrote:
>> Well, it shouldn't be enabled by default.  That slows down all rdtsc
>> operations for the benefit of very niche applications.  The Xen
>> clocksource assumes that rdtsc is fast, unemulated and in need of
>> correction.
>>
>> If someone really needs an artificial tsc, then they can enable the
>> option for themselves.
>>     
> While I understand and sympathize (and the idealistic side of me even
> agrees with) your position, 
>   


Please, no.  I think you've managed to completely misunderstand
everything I've said on this subject.

The TSC is not, and has never been reliable.  At best it has periods of
reliability in which its possible to get coherent results, but never for
indefinite periods.  That includes the recent architecture updates,
though they have considerably increased the periods of reliability. 
This is not an idealistic statement; it is the conclusion from years of
attempts to use the tsc as a time source.  It does not matter what the
documents say, there's always a creative new way for hardware to break
the tsc's behaviour.

There is no requirement for Xen to emulate a hardware feature better
than native.  In particular, there's no need for Xen to synthesize the
platonic ideal of a TSC when existing hardware platform does not do so.

That said, I have no problem with making such emulation an option if it
really helps real programs in the field.  I wouldn't even mind having it
on by default...

Except that it comes with a terrible cost.  rdtsc is a very heavily used
instruction, because its part of the Xen clock ABI.  It gets executed
many thousands of times a second, including at least once every context
switch.  Adding the overhead of an extra synchronous emulated
instruction trap into Xen is going to have a very noticeable performance
hit.

This is a massive regression in everyday, every-system, every-user
performance to satisfy the hypothetical requirement of abstract apps
which may or may not exist.

The fact that you haven't named a single real app that breaks in the
current system and then works with a synthetic TSC further undermines
your argument.  Are you really arguing on the basis that "some apps
might use tsc in a fragile way" or do you actually have a specific list
of apps that are really suffering?  What are they?  How do they break? 
How many users do they have?  What are they doing with the tsc?  Why
can't they use some other mechanism?

I think a change of this magnitude needs a lot more justification than
some handwavy arguments from (dubious) first principles.

    J