Question about interrupt threads

Aniruddha Bohra bohra at cs.rutgers.edu
Wed Apr 23 17:04:49 PDT 2003


Hello
    Thanks for your answer. I have some questions though

>>   My question is after all subsystems that lock giant are made
>>INTR_MPSAFE will the implementation go back to non-process
>>context interrupt handling (as in older versions) ?
>>    
>>
>
>I would like that, but don't see how it could work right.
>  
>
Provided all ISRs spin on their locks, and do not sleep, we can assume the
critical section to be small enough as to not allow interrupt handlers 
on other CPUs
to spin for a long time. Then, the problem does go away. Or am I missing
something important here ? Understandably while there is a GIANT lock
protecting ISRs, this is not possible.

>>   Finally why do we need to create a kernel thread for
>>each IRQ - why can't one kernel thread handle all the
>>IRQs ?
>>    
>>
>
>First, multiple threads are useful because they can be prioritized and
>scheduled independently.  This is probably not very important for
>interrupts provided there is no slow PIO hardware for critical devices
>so that no interrupt handler wants more than a few usec at a time (just
>run the critical devices round-robin and defer processing for the
>non-critical ones to timeout routines).
>
>Second, multiple threads are needed so that they can block on locks
>independently.  I think we actually use 1 thread per device driver to
>irq attachment, so we have multiple threads per irq in the shared irqs
>case.  This is probably needed to let independent device drivers of
>device that are attached to the same irq block independently.  We don't
>seem to have any examples of 1 thread per device giving multiple threads
>per irq withing 1 driver, perhaps because few drivers are fully SMP-aware
>internally.
>
>I would like at most 1 kernel interrupt thread per CPU, but don't see
>how it could work right.
>

Again the assumption is that the Interrupt handlers would block...
If they are non-blocking as they should be ideally, the problem of
blocking on independent events goes away.
As you say the handlers should not take more than a few usecs anyway.

Thanks,

Aniruddha





More information about the freebsd-smp mailing list