Re: announce: PPSkit patch for Linux 2.4.2 (pre6)

Re: announce: PPSkit patch for Linux 2.4.2 (pre6)

[Ulrich Windl]

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.

Ulrich

On 9 Apr 2001, at 18:39, Andreas Bussjaeger wrote:

> > from the current CPU. All these values seem highly suspect. However a 
> > few more values would be helpful to diagnose the situation.
> 
> I have to tell you that I have one 533 MHz Celeron and one 433 MHz
> Celeron.
> 
> > indicate that the CPUs are 968ms apart (each CPU half from the average).

Re: announce: PPSkit patch for Linux 2.4.2 (pre6)

[H. Peter Anvin]

Followup to:  <3AD2CE98.28151.46E93A@localhost>
By author:    "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: announce: PPSkit patch for Linux 2.4.2 (pre6)

[Alan Cox]

> 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

Re: announce: PPSkit patch for Linux 2.4.2 (pre6)

[H. Peter Anvin]

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

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt