Followup to: <3AD2CE98.28151.46E93A@localhost>
By author: "Ulrich Windl" <[email protected]>
In newsgroup: linux.dev.kernel
>
> Hi, Cycle Counters,
>
> Linux currently tries to synchronize TSCs for consistent time in SMP
> systems. One would not believe what combinations of hardware are tried,
> especially for precision timing. Here's a short answer to my asking-
> back about a complaint (the kernel is reporting negative time warps).
>
> As any problem, it can be solved with some overhead, but should it be
> done?
>
> Replies to me too, as I'm not subscribed, please.
>
> >
> > I have to tell you that I have one 533 MHz Celeron and one 433 MHz
> > Celeron.
> >
Hi there,
We have talked about assymmetric multiprocessor configurations once or
twice around. The easy way to deal with them is simply to use
"no-tsc" on the command line (and/or compile your kernel
appropriately.) One could, at least theoretically, make them usable
in kernel space only (in user space there is no hope, since you can't
know which CPU's TSC you're reading), but these machines seem to be so
rare that hardly anyone technical enough to fix it cares.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
> appropriately.) One could, at least theoretically, make them usable
> in kernel space only (in user space there is no hope, since you can't
> know which CPU's TSC you're reading), but these machines seem to be so
> rare that hardly anyone technical enough to fix it cares.
Im working on making the 'notsc' automatic. Trying to 'fix' it is just plain
hard work. With the fixed one however we can still use the tsc for udelay
as we have per cpu loops_per_jiffy data.
This btw is why -ac figures out the bus multiplier on your processors. If they
dont match then we know tsc wants to be off. Just nobody has written the code
to disable it across all CPUs yet
Alan Cox wrote:
>
> > appropriately.) One could, at least theoretically, make them usable
> > in kernel space only (in user space there is no hope, since you can't
> > know which CPU's TSC you're reading), but these machines seem to be so
> > rare that hardly anyone technical enough to fix it cares.
>
> Im working on making the 'notsc' automatic. Trying to 'fix' it is just plain
> hard work. With the fixed one however we can still use the tsc for udelay
> as we have per cpu loops_per_jiffy data.
>
> This btw is why -ac figures out the bus multiplier on your processors. If they
> dont match then we know tsc wants to be off. Just nobody has written the code
> to disable it across all CPUs yet
>
Yes, there are two cases where we can "fix" it: in the timer interrupt
code, and the loops_per_jiffy stuff.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt