:I think you're thinking this:
:
: /-----int 1
:spl -<---> int 2
: \-----int 3
:
:spl messing with several mutexes, instead consider:
:
:int 1 >---\
:int 2 >---->-- splmutex
:int 3 >---/
Problem #1: Different spl levels use different combinations of interrupts.
Some interrupts belong to several spl sets.
Problem #2: Mutexes that you compete for on a regular basis cost cpu
cycles to own. Combining spl bits into a smaller set of mutexes will
exasperate this problem -- it will almost be as if we had a BGL.
:Where a single mutex is shared by several interrupts.
:
:There's also this to consider:
:
:proc0: splaaa(); splbbb();
:proc1: splbbb(); splaaa();
:
:deadlock. Which needs to be worked out somehow.
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Yes, which is one of the many reasons why all current spl() manipualtion
must be done while holding the BGL.
I think the best way to approach solving the spl problem is to not
attempt to migrate the spl interface. Instead we slowly replace it in
a piecemeal fashion.
It would work like this: Any existing code using the spl API *MUST*
hold the BGL. In order to remove the BGL requirement the code, amoung
other things, must migrate to the 'new' mutex interface (or whatever
API we come up with). Both the old and the new interfaces would be able
to work in tandem.
This way we split the problem into multiple pieces rather then attempt to
shoehorn the existing SPL mechanism into the ultimate SMP solution
(instead it becomes only an interim solution, but one that can be 'mixed'
with whatever the real solution winds up being).
This allows us to solve the problem in a piecemeal fashion and reduces
the chance of breaking the code base in a nasty fashion.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
