[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |