pcp
[Top] [All Lists]

Re: [pcp] proc/interrupts parsing fix for large CPU counts

To: Arthur Kepner <akepner@xxxxxxx>
Subject: Re: [pcp] proc/interrupts parsing fix for large CPU counts
From: nathans@xxxxxxxxxx
Date: Mon, 31 Jan 2011 20:05:56 +1100 (EST)
Cc: pcp@xxxxxxxxxxx
In-reply-to: <604285831.67831296464202132.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxx>
Sender: nscott@xxxxxxxxxx
----- "Arthur Kepner" <akepner@xxxxxxx> wrote:

> The linux pmda assumes that /proc/interrupts contains lines formatted
> 
> like so:
> 
> 123:   1    2   3   .....
> 
> i.e., the interrupt number is precisely 3 characters wide. It's 
> usually 4 characters wide on larger systems.

Apologies for the delay, fix is good.  Its a bit academic with your
fix, but I think this format actually is now used for all systems -
I noticed my laptop running a fairly recent kernel prefixes every
interrupt line with at least one whitespace now, so I had the same
problem you saw but on a dual core laptop.

> This fixes it.

OOC, does anyone use this metric (kernel.percpu.interrupts)?  Mark and
I have been discussing changing the model here (which currently mashes
2 instance domains together - cpus and interrupt lines) to make use of
the newer dynamic metric namespace functionality.  This would have the
effect below ...

$ pminfo -f -m kernel.percpu.interrupts
...

kernel.percpu.interrupts.line4 PMID: 60.49.2
    inst [0 or "cpu0"] value 1
    inst [1 or "cpu1"] value 1

kernel.percpu.interrupts.line1 PMID: 60.49.1
    inst [0 or "cpu0"] value 40063
    inst [1 or "cpu1"] value 36753

kernel.percpu.interrupts.line0 PMID: 60.49.0
    inst [0 or "cpu0"] value 6564744
    inst [1 or "cpu1"] value 6712517

I'm thinking of merging these changes after the next PCP release, and
I am keen to hear if anyone thinks they will be adversely affected...?

cheers.

-- 
Nathan

<Prev in Thread] Current Thread [Next in Thread>