Messages in this thread | | | Date | Mon, 28 Feb 2000 12:25:18 -0600 | From | Boris Okun <> | Subject | Re: gettimeofday non-monotonic on SMP 2.3.47 |
| |
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/
| |