Re: 2.6.20-rc6-mm3

From: Daniel Walker
Date: Tue Feb 06 2007 - 17:42:41 EST


On Tue, 2007-02-06 at 23:08 +0100, Ingo Molnar wrote:

> sorry but that's precisely what your suggestion above results in:

I'm not trying to suggest we "fake" anything. Your just misunderstanding
me.. I'm am suggesting we change LOC to something readable. If you think
we're "faking" something by dropping the current "timer" request_irq()
then we certainly don't need to do that ..

The io-apic timer could potentially be a clock event device, that is
it's function isn't it ? It generates interrupts (note I said
interrupts) periodically .. The NMI is another example of that,
generates non-maskable interrupts based off a clock.. All are clock
based interrupt generating devices .. All could be clock event sources,
with all the other clock event sources in the system.

It makes sense (to me at least) that we should list all those interrupt
generating devices in /proc/interrupts with statistics of their usage..

I'm making suggestion here, you can call it "fake"'ing something or
whatever, but I'm still going to pose suggestions.

> > > > If we change the current "timer" entry to be listed as
> > > > "lapic-timer" and not "IO-APIC-edge" (or one of the other names)
> > > > and replace it with the count from LOC
>
> "replace the timer entry with lapic-timer and put the LOC count there"
> is faking something that does not reflect reality. The 'timer' count is
> for IRQ#0, not for the local apic timer.
>
> > [...] I'm saying list what's really happening .. In a human readable
> > way .
>
> we list precisely what is happening: the number of IRQ#0 interrupts and
> the number of local APIC timer interrupts. Precisely where their
> traditional place is.

Empirically, I know that users do not/will not understand what's
happened. so take that how ever you want, but _I_ think we should do
something so people better understand what has happened.

Daniel

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