On 09/29/09 16:45, Dan Magenheimer wrote:
> Let me attempt to summarize our disagreement and then
> I'd like to stop arguing.
>
> 1) You think rdtsc is never safe for an app to use. I
> think it is safe in many hardware/software enviroments
> and that the number of safe environments will continue
> to increase.
>
I think its highly unadvisable, and hard to do correctly. I think there
are better ways to achieve the same effect. I think you are flat-out
mistaken in your faith in "safe environments"; such safe environments
are certain machines qualified on a case-by-case basis, and can never be
assumed to be generally available baseline configuration. You have not
supported your faith in "safe environments" with any concrete documentation.
> 2) You think the performance hit from rdtsc-emulation
> is horrible. I think it is significant but relatively
> small and acceptable and, if there are cases where it
> is not, administrators or virtual appliance providers
> can make an informed choice to turn it off.
>
When evaluating any performance hit one has to take into account who
benefits versus who suffers. The pool of applications and users who
could possibly benefit from synthetic tsc is very small, whereas every
single user will suffer some performance degradation resulting from
synthesizing the tsc.
> 3) You think app developers can and should be told to
> not use rdtsc because it is inherently unsafe and
>
Application developers have been consistently told and advised not to
use rdtsc in usermode in all Linux environments; Linux under Xen is no
exception. Nobody has ever made any guarantees that rdtsc has any
particular behaviour in usermode, nor will they. The only guarantee
that Linux makes is that it will use the tsc in vgettimeofday where
possible.
> so Xen doesn't need to ever be concerned with making it
> safe.
I don't have any problem with allowing synthesis as an option, or even
making it the default for hvm guests. But I object to interfering with
an important PV ABI, for two reasons:
1. it has a negative impact on all the kernel uses of rdtsc, which
are safe
2. it prevents a high-performance vsyscall implementation to allow
safe, fast usermode access to the tsc
In other words, it makes things worse for everyone who is doing things
the right way, for the sake of mitigating the risks of unsafe code.
> I think app developers will do what they
> please, ignorant to the subtleties of rdtsc, and if
> their app works on their hardware and on VMware but
> not on Xen, they will blame Xen or Linux or their
> OS provider or their cloud provider, and probably never
> know that their app doesn't work because of rdtsc.
>
Shrug. They can blame who they like. It is no different from
developers who write buggy multithreaded code that appears to work fine
until they move to more cores, or a different system topology, or
different libraries or compiler or OS or...
It is not recommended for Linux. Microsoft does not recommended it for
Windows.
Developers are consistently advised not to use rdtsc in usermode. There
are no standard library functions to access it directly, so they must go
out of their way to do so. Pretending that the TSC is safe or advisable
to use in usermode is just going to lead developers astray and enable
bad habits. When a drug addict blames the rest of the world for their
affliction, the answer is not to give them more drugs.
That said, just as one can use Xen's various mechanisms to approximate a
machine layout in order to work around bugs in MT programs, I don't have
any particular problems with tsc-synthesis to work around buggy
programs. But it should not be on by default.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home