Re: [PATCH] tsc-disable_B9

[Andrea Arcangeli]

On Fri, Aug 16, 2002 at 03:19:31PM +0200, Mikael Pettersson wrote:
> Alan Cox writes:
>  > On Thu, 2002-08-15 at 17:56, Andrea Arcangeli wrote:
>  > > sorry but I don't see the point of badtsc only in kernel.
>  > > 
>  > > If the TSC is bad that will be in particular bad from userspace where
>  > > there's no hope to know what CPU you're running on.
>  > 
>  > You can still do meaningful measurements for things like profiling
>  > because the cpu hop is statistically uninteresting.
> 
> There are kernel extensions around that handle process migration across
> CPUs while providing virtualised per-process TSC counts, and for which
> the TSCs do NOT need to be in perfect sync.

you mean trapping the instruction fault and emulating the tsc with a
gettimeofday? In such case you should run gettimeofday in the first
place. that's the whole point. rdtsc means rdtsc, not a software
emulation of it. If you don't want to bind your userspace to a certain
system that has tsc in sync, you should use gettimeofday since the first
place so it'll run on non x86 too.

Infact returning an instruction fault is probably one of the best way to
allow a program to autodetect if the tsc is useful. Otherwise if you
left the tsc enabled, it'll be hard for userspace to guess if the tsc
are in sync (you could with cpu binding but only if you have
privilegies, normal programs wouldn't be capable of probing that).

> Disabling user-space RDTSC just because the TSCs aren't in sync is stupid.

what you mean as non stupid has to be to still disable it (so figure out
how much disabling it is stupid) and to trap the instruction fault and
software emulate the tsc so that userspace will think the TSC aren't
disabled while they're are infact disabled.

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.

Andrea