Artur Skawina wrote:
>
> Boris Okun wrote:
> >
> > Faulty hardware is certainly a possibility, but how can it be SMP
> > specific?
>
> see below while it only applies to SMP.
>
...
> modern cpus have a "Time Stamp Counter" in them; that's basically a
> hardware register, in the ia32 case it's a 64 bit register incremented
> for every cycle. linux check if the cpu contains this feature while
> booting, and if yes - uses it to obtain precise time. Once you know
> the rate at which this counter is increasing (which you can get by
> using an external, not-on-cpu timer to measure it) finding the
> current time is basically done by properly scaling the TSC value.
> now, if like in your case, the TSC runs at different speeds on both
> processors, there is no single scaling factor. So trying to use
> only one means you get wrong results on at least one cpu.
> the solution to that could be to have per cpu cycles/s values instead
> of a global one. see linux/arch/i386/kernel/time.c for the actual
> code.
Artur,
Thanks for the explanation. Actually, I was talking about the situation
after applying Andrea's patch, which essentially made
do_gettimeoffset=do_slow_gettimeoffset which does not use TSC.
In general, I think it is a bad idea to rely on 2 (or more) hardware
counters being always the same. I think the right solution is just to
use one of them. (Of course I am biased ;-). I can imagine an SMP laptop
where one processor sleeps most of the time...
How hard is to force reading TSC of just say the boot processor in
do_gettimeoffset?
I am more than willing to do the leg work if somebody points me to the
right direction.
Boris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:20 EST