Interrupt Threads

[John Baldwin]

On Friday, September 17, 2010 11:38:54 am Julian Elischer wrote:
> On 9/17/10 8:23 AM, John Baldwin wrote:
> > I have wanted to rework some of the interrupt threads stuff and enable
> > interrupt filters by default for a while.  I finally sat down and
> > hacked out a new ithreads implementation at BSDCan and the following week.
> >
> > The new ithreads stuff moves away from dedicated threads per handlers or irqs.
> > Instead, it adopts a model more akin to what Solaris does (though probably not
> > completely identical).  Each CPU has a queue of "pending handlers".  When an
> > interrupt fires, all of the handlers for that interrupt are placed on to that
> > CPU's queue.  There is a pool of hardware interrupt threads.  If the current
> > CPU does not already have an active hardware interrupt thread, it grabs a free
> > one from the pool, pins it to the current CPU, and schedules it.  The ithread
> > continues to drain interrupt handlers from its CPU's queue until the queue is
> > empty.  Once that happens it disassociates itself from the CPU and goes back
> > into the free pool.  The effect is that interrupt handlers are now sort of
> > like DPCs in Windows.
> 
> do you gain anything, other than having less threads, by allowing them 
> to migrate?  that means you need more locking between cpus I presume.

Filters really work and all the homegrown taskqueue stuff in many drivers
goes away as it can now be done using the normal interrupt code.  The
locking between CPUs is not any more than it is currently and in fact can be
less in certain cases.  One thing I have not done is to add a notion of
affinity so that a CPU would prefer the last ithread it used if it is still
free when it needs a new ithread.

Also, the code to add and remove handlers is actually simpler than the old
code.

> > 2) Many folks find the ability to see how much CPU IRQ N's thread has used in
> > top useful, but this loses all of that since there is no longer a tight
> > coupling between IRQs and threads.
> 
> yeah we faced this problem with KSEs and user threads.. the lack of 
> coupling also means you lose history which may be useful.

The only thing that is different in this case is that interrupt handlers
have traditionally not had any coupling with anything since they are
asynchronous event handlers similar to signal handlers.  In the case of
threads there is an expected coupling, but less so for signals and
interrupts.

-- 
John Baldwin