Hey Marcelo, all,
Here is the next revision of my tsc-disable patch. Thanks to everyone
for providing feedback. I will re-submit this for the 2.4.20pre series,
but wanted to get this out for additional comments as well as warn folks
who might be trying this or my previous patch. This version reverts to
the earlier implementation, which only changes config.in. I feel that
defining CONFIG_X86_HAS_TSC gives one the ability to discern between
just having a TSC and having a usable TSC, and all the current code that
uses CONFIG_X86_TSC assumes that it is usable. This way seems cleaner
and has all the benefits of the last method. Additionally I added the
previously forgotten Configure.help documentation, for which I should no
doubt receive a ruler across the knuckles.
One semi-large (now documented in Configure.help :)caveat I found: on
systems which have glibc compiled for i686, kernels built with my old
patch would not boot. This is because disabling the tsc makes rdtsc a
privileged operation. When the kernel tries to run init, it hits the
rdtsc in glibc and dies. Therefore in this version you must enable the
option, then pass "notsc" to the kernel at boot. That way, if you run
into problems you can just remove the "notsc" option and get your system
running. Installing a non i686 optimized glibc solves this problem.
Next, at Benjamin and Kurt's suggestion, I'm going to start looking
into per-cpu TSC management, but for now this patch gives an immediate
fix for a known problem (at some cost to performance, but slow numbers
are better then invalid ones).
I know I'm going to get this comment, so I might as well deal with it
now. "Why bother with this patch when you could just compile the kernel
for 386 the net effect would be the same?" Good question, actually. I
almost decided against sending this patch out, but the ability to use
processor optimizations other then CONFIG_X86_TSC seems useful on these
large systems. Additionally having this issue explicitly documented in
the kernel might help those who are wondering why their shiny NUMA
Pentium 4 system can't seem to read its watch properly (rather then
having someone say "just compile for 386" and having them think "but its
a Pentium 4!").
comments and flames welcome.
-john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:18 EST