Re: [PATCH] tsc-disable_B9

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Aug 21, 2002 at 04:01:55PM +0100, Alan Cox wrote:
> On Wed, 2002-08-21 at 15:33, Andrea Arcangeli wrote:
> > But silenty breaking apps and not allowing in any way to apps to learn
> > if the tsc is returning random or if it's returning something
> > significant (I understand that's the way you did it in -ac) is a no-way
> > by default IMHO.
> 
> All such apps and libraries are already broken have been silently broken
> since about 1999 and will continue to be broken. Thats been true since
> speedstep cpus appeared if not before.

certainly fair enough argument in theory, but in practice you're not
going to risk running those apps in a laptop or in general with any
power management that will decrease the frequency of the cpu anytime.
Also the change in frequency wouldn't generate non monothone results,
still the app may malfunction but going backwards or with an huge error
is more likely to be erronic for the tsc users than just the decrease of
frequency.

Furthmore the speedstep right now today can crash any laptop that boots
at reduced mhz and that switches to higher mhz at runtime, that change
of the tsc frequency simply make udelay run faster, and it'll break
drivers easily. I suspect there's even an unfixable race condition in
the speedstep hardware since it's not the kernel asking for the change
of frequency (at least when not using ACPI), so the change of frequency
when you plugin power may happen right before the start of udelay, we
may have irq disabled and the udelay will take less without a chance to
recalbirate delays.

Returning to our tsc issue, these "broken apps since 1999" may now
run run silenty on these numa machines that obviously cannot provide any
significant info via the tsc to userspace, and there's no way to know
that your app isn't breaking because of numa, unless you disable the tsc
to userspace.

Feel free to argue further but that won't change the fact you will never
know if your apps is getting confused or not if you don't disable the
tsc and you don't let it get the instruction fault. it is just
impossible with -ac (hmm, ok you could objdump all the binaries and libs
and hope there's no self modyfing code :)

And following your argument that these apps have been silenty broken
since 1999, if there's no broken app out there, nobody will ever get the
instruction fault. If there's any app broken out there we probably like
to know.

Infact following your argument of "broken apps since 1999" we should
disable the tsc on every machine out there, not only on the numa,
lefting a backdoor via prctl or sysctl to allow the profiling. And we
should bug at boot if we notice the cpu isn't at max frequency to avoid
the speedstep instability (but that's another issue).

Andrea