lkml.org 
[lkml]   [2008]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2008-10-02 17:05    [W:0.173 / U:1.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site