Date: Fri, 17 Sep 2010 13:26:11 -0400 From: John Baldwin <jhb@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: Interrupt Threads Message-ID: <201009171326.11182.jhb@freebsd.org> In-Reply-To: <4C938B8E.8050901@elischer.com> References: <201009171123.39382.jhb@freebsd.org> <4C938B8E.8050901@elischer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009171326.11182.jhb>