Interrupt Descriptions

[John Baldwin]

On Thursday 01 October 2009 1:54:15 pm Bruce Evans wrote:
> 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.

I consider having to rebuild the entire namespace when changing one name
a design limitation.  I think it worked fine when you had machines without
hotplug hardware (or drivers) where the set of interrupts in use was
essentially built once during boot and static thereafter.  However, that
is no longer the machines we have.

-- 
John Baldwin