[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1170800020.3785.41.camel@chaos>
Date: Tue, 06 Feb 2007 23:13:40 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: dwalker@...sta.com
Cc: Ingo Molnar <mingo@...e.hu>, Andrew Morton <akpm@...l.org>,
linux-kernel@...r.kernel.org
Subject: Re: 2.6.20-rc6-mm3
On Tue, 2007-02-06 at 13:54 -0800, Daniel Walker wrote:
> > The same happens when say a network driver implements NAPI: the IRQ
> > count goes way, way down. Or if a driver starts supporing MSI - the IRQ
> > line even moves to another one. Do we try to fix those counts up to
> > match the 'previous behavior'? Of course not. What you are suggesting
> > makes no sense, is against current kernel practices - as we pointed it
> > out to you 7 mails ago.
>
> I'm not saying we should "fake" anything .. I'm saying list what's
> really happening .. In a human readable way .
We do that. IRQ0 is not happening. So simply it does not increment the
interrupt count. And it is human readable.
> Your saying we should keep it unreadable, and let the users be that much
> more confused .. Which I don't agree with.
It is readable, as it reflects the reality which is going on in the
system and not some artificial view which you think is how the interrupt
count should be presented. /proc/interrupt _IS_ statistics about the
number of interrupts on particular interrupt numbers and nothing else.
> Why is that not the case with lapic ?
Local APIC is not really part of the interrupt subsystem as it uses a
seperate entry vector for historic reasons and therefor is not handled
by setup/request/free/... _irq() functions.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists