Interrupt Descriptions

[Bruce Evans]

On Thu, 1 Oct 2009, John Baldwin wrote:

> For the ithread name we are stuck with MAXCOMLEN.  I would like to overhaul
> the intrcnt stuff to possibly allow for longer names and be mostly MI (having
> all the longs shared across cache lines that might be shared by multiple CPUs
> isn't ideal either at this point).  I am considering having either an array or
> list of intrcnt structures with a name and a count with a sysctl that exports
> an array for vmstat to use (the kvm bits could always rebuild the list using
> the same logic as the sysctl handler for crash dumps).  The current design is
> very limiting and forces the weird space padding to make renaming intrcnt
> descriptions manageable when adding/removing interrupt handlers.

The design has few limits.  My old implementation had no limits on
name lengths.  It just had a limit on the combined length, due to it
allocating the string space statically.  String spaces without padding
require about 10 extra lines to create and zero extra lines to use
(since the users already expect a string space so they already have
the extra lines to walk over it).  Changing the descriptions, including
rebuilding the whole string space whenever an interrupt handler is
added/removed/renamed shouldn't be a problem since this is a rare
event.  Just lock out the sysctl and other accesses to the string space
while changing/reallocating the string space.  Counters are harder --
you can't move them without locking out interrupt handlers that
increment them.

You could also delay rebuilding until the sysctl (wouldn't be so easy
for kvm).  The sysctl would take longer, but perhaps no longer than
now since the data size should be much smaller -- instead of 100's of
padded strings there should be only a few unpadded ones (the strings
on ref8-i386 now consists of 49 "stray irqN" (padded), 42 unused "irqN:"
(padded), one "???" (padded; unused I think -- this "???" is for when
the table fills up and/or when an unexpected irq occurs, but the table
now covers everything and has zillions of stray slots for unexpected
ireq), and 15 lines for interrupts actually attached (8 lapic timer,
2 moderately used, 1 rarely used, 3 never used).

systat wouldn't like the tables' sizes or string contents changing
underneath it, but in the rare event that this happens it couldn't do
worse than crash, and it could detect the change using a new generation
count.  vmstat wouldn't have any problems since it only reads the tables
once (minor race between the independent sysctls).

The kvm interface doesn't support dynamic table allocation.  You would
probably have to change it eventually to support per-CPU counters if
you actually want to keep supporting interrupt stats in dead kernels.

Bruce