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:
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/