[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)
Ian Pratt 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
>>> 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, let me argue your point "they can enable
>> the option for themselves" by mangling a famous movie quote:
>> "In a cloud, no-one can hear rdtsc scream"
> If we had some actual bug reports detailing failures of real-world
> applications then the decision would be easy.
> I realise it could be hard to pin strange application behaviour down
> to TSC issues, but I can't readily spot any bugs on the XenServer or
> xen.org bug trackers that might even be candidates.
Maybe Dan can give more reasons. I think the TSC skew issue should be thre key
one. But IMO, the TSC skew issue maybe not that important. In real-world apps,
rdtsc is mostly read by the kernel syscall gettimeofday, and kernel can
eliminate the skew before returning to user app through returning the value
"plus 1 on last_tsc". Even if apps use "raw rdtsc" instruction to get timestamp
in rare cases, I think the issue also can be solved by apps' ownself through a
simple check. Therefore, I still can't figure out the suasive reasons why
adopts emulation way for the tsc read so far.
Any other necessary reasons to introduce it except fixing skew issue
Xen-devel mailing list