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}.*
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.
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
Cheers
-- Mark
|