Re: [patch] oprofile for ppc

From: Benjamin Herrenschmidt (benh@kernel.crashing.org)
Date: Mon Mar 10 2003 - 03:43:00 EST


On Mon, 2003-03-10 at 07:31, Albert Cahalan wrote:
> On Sun, 2003-03-09 at 22:50, Segher Boessenkool wrote:
> > Benjamin Herrenschmidt wrote:
>
> >> Beware though that some G4s have a nasty bug that
> >> prevents using the performance counter interrupt
> >> (and the thermal interrupt as well).
> >
> > MPC7400 version 1.2 and lower have this problem.
>
> MPC7410 you mean, right? Are those early revisions
> even popular?
>
> I'm wondering if the MPC7400 is also affected.
> The MPC7400 has some significant differences.
> The pipeline length changed.

7400 and 7410 are quite similar. I had the problem on
my old G4 which is a 7400 (I don't have it any more so
I can't tell you about the CPU rev).

> >> The problem is that if any of those fall at the same
> >> time as the DEC interrupt, the CPU messes up it's
> >> internal state and you lose SRR0/SRR1, which means
> >> you can't recover from the exception.
> >
> > But the worst that happens is that you lose that
> > process, isn't it? Not all that big a problem,
> > esp. since the window in which this can happen is
> > very small.
>
> I think you'd get an infinite loop of either
> the decrementer or performance monitor. That's
> mostly fixable by checking for the condition and
> killing the affected process, but that process
> could be one of the ones built into the kernel.

You can lose the kernel state as well

> So the use of oprofile comes down to a choice:
>
> a. Ignore the problem.
> rare crashes

Not that rare as soon as you increase the interrupt frequency

> b. The decrementer goes much faster for profiling.
> high overhead, awkwardness in non-time measurement

The overhead of a single DEC interrupt isn't _that_ high

> c. The performance monitor is used for clock ticks.
> hard choices about sharing or frequency
>
> Besides the obvious use of core cycles to generate
> a clock tick out of the performance monitor, there
> is the tbsel field in MMCR0. That has some strange
> frequency choices. On a system with a 100 MHz bus,
> it looks like one gets:
>
> 12.5 MHz, 49 kHz, 3 kHz, 191 Hz
>
> So 3 kHz it is. That's 1526 Hz on a 50 MHz bus,
> or 6104 Hz on a 200 MHz bus. This is enough to
> get a 1000 Hz jiffies with reasonable jitter on
> most machines, and a very good 100 Hz for user apps.
>
>
> ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:21 EST