Date: Mon, 27 Mar 2000 13:47:09 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Daniel Eischen <eischen@vigrid.com>, Nate Williams <nate@yogotech.com>, nms@otdel-1.org, freebsd-current@FreeBSD.ORG Subject: Re: Is there spinlocks/semaphores available for drivers? Message-ID: <200003272147.NAA43734@apollo.backplane.com> References: <Pine.SUN.3.91.1000327142313.16202A@pcnet1.pcnet.com> <200003272008.MAA42799@apollo.backplane.com> <20000327135414.M21029@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
: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 - [bright@wintelcom.net|alfred@freebsd.org]
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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003272147.NAA43734>