Re: [PATCH] tsc-disable_B9

[Andrea Arcangeli]

On Thu, Aug 08, 2002 at 07:30:46PM -0700, john stultz wrote:
> On Thu, 2002-08-08 at 06:17, Alan Cox wrote:
> > On Thu, 2002-08-08 at 02:53, john stultz wrote:
> > > already seen on another cpu. This patch allows people compiling w/
> > > 'Multi-node NUMA support' to pass "notsc" or "bad-tsc" as boot
> > > parameters. "notsc" disables rdtsc calls, and forces the kernel to use
> > > the PIT for gettimeofday calucluations (as normally expected w/ i386
> > > compiled kernels). While "bad-tsc" forces the kernel to use the PIT for
> > > gettimeofday, but does not disable TSC access. 
> > 
> > I've done a version of this for -ac which uses the NUMA autodetect, and
> > also provides the hook so I can disable tsc on split on x86 smp with
> > variable multipliers some time. The only comment I really have is please
> 
> Not sure I followed that, do you mean per-cpu TSC management for
> gettimeofday? 
> 
> > use "badtsc" not "bad-tsc" - to match "notsc"
> 
> Sounds good. Changed in my tree.

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.

If the TSC is bad userspace is the one that must not be allowed to read
the tsc at all, the tsc in userspace could only have a function of a
random number generator.

So I suggest to drop the badtsc and to only have the notsc that disables
the tsc globally for both kernel and userspace. That's what I'm doing in
my tree for the above reasons at least.

> > This is how I did it - barring the code that is -ac specific to automatically flip
> > the mode when NUMA hw is detected
> 
> Interesting. See my comments below.  Auto-detection has been on my list
> for the last week, so I'm eagerly awaiting a peek at the next ac release
> :)

How do you detect the NUMA hw? That would be a nice addition so the
numa-Q users won't be required to add notsc to the append lilo line.

My current preferred status for this patch is here:

	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19rc5aa1/94_numaq-tsc-4

I'm fine to drop the #ifdefs and to allow notsc to be significant
always if you like, however also requiring a numa compilation like now
should be fine, no? At least unless you can detect the badtsc
dynamically also in kernels with numa disabled, which isn't the case
right now I guess.

But still the "allowing badtsc in userspace" in the last patches looks
obviously wrong to me, the "emulate tsc in inst fault" was better, but
even that sounds not the best, all programs should have a fallback to
use gettimeofday so it's better to get the instruction fault immediatly
rather that running slow because of the flood of exceptions that happens
silenty.

Andrea