On Mon, 30 Jul 2007 10:33:17 -0700
Sven-Thorsten Dietrich [off-list ref] wrote:

On Thu, 2007-07-26 at 11:56 -0700, H. Peter Anvin wrote: 

quoted

Joe Korty wrote:

quoted

Create /proc/all-interrupts for some architectures.

Create a version of /proc/interrupts that displays _every_
IRQ vector, not just those that someone thought might be
interesting, and add an entry in the commentary column
for those vectors which lacked such a comment.

Rationale: /proc/interrupts is not truly useful unless it
displays every IRQ vector, not just those somebody thought
would be interesting.  For example, since /proc/interrupts
does not display the rescheduling interrupt, the occurance
of rescheduling interrupt floods ends up affecting
latencies, yet without an entry in /proc/interrupts, it
is difficult to discern why latencies are being affected.

Rather than modify /proc/interrupts, this patch creates
a new version of /proc/interrupts, on the off-chance
that adding new lines to /proc/interrupts, and appending
new fields to the end of old lines, might break some
longstanding script.  However, these kinds of changes
traditionally do not affect scripts, so it might be
reasonable to fold /proc/all-interrupts back into
/proc/interrupts.

I think that would be the right thing to do.  We have added things to
/proc/interrupts in the past.

Hi Andrew,

Would it make sense to drop this patch into -mm for feedback?

It's a lot of code for something which might be useful to someone sometime.

It's a bit of a crappy changelog too.  I'd at least like to see a list of
all the new fields.

It should be OK to add new lines to /proc/interrupts?  That file varies a
lot between machines adn between architectures - as long as the new lines
have similar layout it is unlikely that anything will break.



+	atomic_inc(&__get_cpu_var(irq_thermal_counts));

The patch does atomic ops on cpu-local variables.  This isn't needed, and
is expensive.

If the field is only ever modified from hard interrupt context then you can
make the field unsigned long and use plain old `foo++'.

If the field is modified from both hard-IRQ and from non-IRQ then use a
local_t and local_inc.

Or even, given that this is just a statistic and grrat precision is not
needed, use unsigned long and f++ even if that _is_ racy.  Because the
consequences of a race will just be a single lost count, which we dont'
care about enough to add the additional overhead of an atomic op.


But I'm a bit dubious about the whole thing, really.  As I said, it's a lot
of code.  More justfication is needed for its addition, I'd suggest.