Messages in this thread | | | Date | Thu, 2 Oct 2008 11:02:50 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers |
| |
On Wed, 1 Oct 2008, Daniel Walker wrote: > > > > Converting an interrupt to threaded makes only sense when the handler > > code takes advantage of it by integrating tasklet/softirq > > functionality and simplifying the locking. > > I'm not clear on your direction here.. I don't have a problem with a > mass driver audit, which I think is what your suggesting with this patch > set .. However, a mass audit like that would push a fully real time > system out for quite some time..
This has nothing to do with real time, although it helps.
> > I also don't see a clear connection between these changes and ultimately > removing spinlock level latency in the kernel. I realize you don't > address that in your comments, but this is part of the initiative to > remove spinlock level latency..
This is a completely different topic.
> > So with this set of changes and in terms of real time, I'm wonder your > going with this ?
This helps with latencies and locking. With the current scheme of hardirq, softirq/tasklets, there are a lot of craziness with spin_locks and spin_lock_irqs and mutexes.
By creating an interrupt thread, we can skip the softirq/tasklet altogether, and this simplifies locking.
There are other cases where threaded interrupt handlers also improve performance. But we will get to those in due time.
-- Steve
| |