Matthew Dillon wrote:
> The answer is.... nobody knows yet :-).
>
> Interrupts will probably wind up running each in its own thread, and
> we will probably adopt the BSDI hybridized model (which runs an interrupt
> synchronously if possible and spools it to a thread otherwise) to
> increase efficiency.
>
> I outlined a way to keep the current spl/cpl mechanisms intact while
> at the same time moving interrupts to a threading model in my SMP
> document:
>
> http://www.backplane.com/FreeBSD4/
> http://www.backplane.com/FreeBSD4/smp-api.html
>
> The mechanism I outline will allow interrupt execution concurrent
> with supervisor execution, and allow interrupt execution concurrent
> with other interrupts. For example, two different ethernet interrupts
> could be taken concurrently with only minor spinlock controls
> on the IF queue, and both could run concurrent with the TCP stack
> (outside of the spl*() protected areas of the TCP stack).
I had a look at (VI) Interrupt-Disabling Spin locks.
Wouldn't it be better to use priority inheritent mutexes of some sort.
If an interrupt thread tries to take a mutex that is held by another
lower priority thread, then the interrupt thread would lend its priority
to mutex/lock holder. Interrupts would only be disabled while taking
the lock and setting the owner field, then could be reenabled immediately
afterwards. This would let drivers protect potentially time-consuming
sections of code without blocking interrupts.
I really dislike spinlocks and am afraid of priority inversion problems.
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
