I *suspect* you already know the "right answer" to most of these
problems. You should avoid ordering dependencies with soft interrupt
handlers -- the system makes no guarantees, and I believe that that
there is indeed a single thread that processes them. (I think its
actually a thread for each interrupt level, but I've not checked more
closely.)
I believe the only good reason to soft interrupts is to get out of *high
level* interrupt context into a lower priority one where you can safely
do things like access normal system mutexes and do ddi_taskq_dispatch.
Unless you're working with hardware with some very specific timing
constraints (e.g. a serial port driver with a small or non-existent
FIFO), you probably shouldn't be using soft interrupts at all.
Taskq's are IMO a better way to execute code on a different call stack,
and can offer higher performance/scalability than soft interrupts.
Ultimately, rearchitecting your code around taskq's may save you
significantly more time than the effort to hack around the limitations
of soft interrupts. (To say nothing of improvements to robustness &
scalability.)
-- Garrett
Joachim Worringen wrote:
> Joachim Worringen schrieb:
>
>> Greetings,
>>
>> we are writing a stack of layered kernel modules (actually, port it from
>> Linux), with a hardware-handling driver at the bottom (call it A), and a
>> module B that calls down into A. Next to this, A does upcalls into B.
>>
>> A softint handler "si_B" (created and triggered) within B is waiting by
>> blocking on a sema_p(). The correspondig sema_v() is to be performed
>> within an upcall of a softint handler "si_A". si_A was created within A,
>> and triggered there from a hard interrupt (level 12). Both handlers si_A
>> and si_B have the same max. softint priority.
>>
>
> Ok, seems I have to reply myself... Creating si_B with the min. softint
> priority fixed the problem. It seems that the softints of the same
> priority are actually executed strictly sequentially.
>
>
>> What we see now is that si_B is not signaled (by succeeding with the
>> sema_p()), as si_A is trigged successfully, but not executed. Looking at
>> av_dispatch_softvect()
>> (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/avintr.c#av_dispatch_softvect),
>>
>> it seems that one possible cause for this is that softint handlers are
>> executed sequentially, being called from the loop in this function.
>> Could this cause this deadlock ?
>>
>
> [see above]
>
>
>> A related question is then: if I create multiple softint handlers (all
>> with the same priority) within a driver, will they ever be executed
>> concurrently?
>>
>
> We will evaluate this with a simple test module, but from what I've seen
> so far, I expect the answer to be "no". I will post results here.
>
> Joachim
>
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
