Done right the TSC patch isnt that big a kludge IMHO. You need to build aHi Alan,
non TSC capable kernel which means the do_gettimeoffset function vector
is already there and the overhead is already taken.
It doesn't appear that way to me. (But of course, I have
very little experience with the
internals of linux, and may be way off-base ;-) ).
So, I probably should find out what the difference is between
TSC and non-TSC, but
what concerned in the patch was the removal of
#define do_gettimeoffset() do_fast_gettimeoffset()
from the else clause of
#ifndef CONFIG_X86_TSC
so it looks like, if CONFIG_X86_TSC is defined, the kernel will
now use a proc var
instead of this macro. Did I miss something here?
If this is going to be added, I have a few other comments:
Would it be possible to use the calculated the processor
speed instead of the calculated
BogoMIPS:
<from my logs>
Apr 10 18:00:04 kernel: Detected 333058429 Hz processor.
It seems like this would be more accurate, the comments in the code
state that it
is accurate to 100 ppm.
One final comment: Can we have a silent success path. ie don't
include
the following:
printk(KERN_INFO "CPUs have the same speed, enabling TSC\n");
By not seeing the error message, the kernel must have passed it.
Or if it stays in
maybe say "Enabling TSC (<whatever TSC stands for>)\n".
Other lines I don't feel belong in the logs:
Apr 10 18:00:04 furball kernel: Checking 386/387 coupling...
OK, FPU using exception 16 error reporting.
Apr 10 18:00:04 furball kernel: Checking 'hlt' instruction...
OK.
Maybe in the 2.5 stream, some type of debug_level could be passed
to the kernel at boot
so users could choose how much detail they want to see in their boot
logs(possible
levels: None, Low, Normal, High, Full).
Thanks,
Mark
It doesnt bite pure TSC kernels at all
