----- "Mark Goodwin" <mgoodwin@xxxxxxxxxx> wrote:
> On 02/01/2011 10:10 AM, nathans@xxxxxxxxxx wrote:
> >> So your proposed change would remove the irq name, and irq chip
> name
> >> information from the instance id?
> >
> > Thats correct. The irq number would become part of the metric
> name,
> > and I was thinking (but haven't implemented this piece yet) that
> the
> > irq chip name - which is basically free form text - could be
> exposed
> > as the metric short help text, e.g.
> >
> > $ pminfo -t -f -m kernel.percpu.interrupts.line0
> >
> > kernel.percpu.interrupts.line0 PMID: 60.49.0 [IO-APIC-edge timer]
> > inst [0 or "cpu0"] value 6564744
> > inst [1 or "cpu1"] value 6712517
> >
> > Using the CPU instance domain has some advantages for client tools
> like
> > pmie, and its alot simpler to traverse (e.g. in pmchart metric
> selector
> > dialog) than the expanded matrix indom format we have now.
>
> yes agree.
>
> We could also create an aliased dynamic namespace for the irq names,
> e.g.
> kernel.percpu.interrupts.{irq_name,irq_number}.*
Yes, thats possible.
> so e.g.
> kernel.percpu.interrupts.irq_name.io_apac_edge_timer and
> kernel.percpu.interrupts.irq_number.line2 would be aliased
> and share the same cpu instance domain.
> Not sure if the irq_name -> irq_number aliasing would be
> persistent across reboots though so it might be a bit awkward,
> especially for log merges.
I'll commit what I've got to dev shortly, and will work on the help
text while you hack on this if you like? And perhaps Arthur could
try it out as a real user too & see if it still meets his needs.
> hmm, come to link of it, the lineN namespace wouldn't be persistent
> either. Perhaps we should go with a combination to avoid ambiguity:
> kernel.percpu.interrupts.line2_io_apic_edge_timer
As long as the interrupt lines don't change (which they wont) then its
all fine... right? The names will stay the same and the IDs will also
AFAICT.
cheers.
--
Nathan
|