Re: [PATCH] tsc-disable_B9

[Andrea Arcangeli]

On Wed, Aug 21, 2002 at 03:10:24PM +0100, Alan Cox wrote:
> On Wed, 2002-08-21 at 14:12, Andrea Arcangeli wrote:
> > However here the point is that the TSC was left _enabled_ (not disabled
> > and emulated as you are advocating) despite it was not in sync. That
> > cannot make any sense, except if you use the tsc as a random number
> > generator.
> 
> Totally untrue. When you are doing profiling the data is very useful
> because CPU switches are trivial to filter and statistically rare

You can use statistic to guess what are the measurements that you've to
filter agreed, however this mostly applies to hot cache measurements
(likely to return many times the same result if there's no error) and in
particular where you are allowed to waste cpu time in repeating many
times the same workload before you say "ok this is the right measure".

Filtering out the errors is not feasible in all the cases, even if you
are allowed to repeat the same measurement multiple times. And it also
depends if you have a 3-way pipe communication in background.

And you'll keep to silenty break in all other applications that uses
rdtsc to know how much time has passed, that can hardly understand if
they can use the tsc or not unless we tell it to them from the kernel.

If you want to use the tsc in a controlled manner using statistic for
just profiling of a certain piece of code where it is easy to
demonstrate the absolute most frequent result is the correct one (as
said it's not always the case, when you do measurements out of hot cpu
cache the masurements vary significantly all the time, you are very well
aware about it), at the very least it should be a  privilegied sysctl or
a non privilegied prctl (prctl however requires a slowdown of
swithc_to). Infact if we add a branch to switch_to we could even
automatically allow it for processes that are bind to a single cpu (or
to a single NUMA node adding some more internal knowledge about the numa
topology).

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.

Andrea