Date: Wed, 16 Jul 1997 14:37:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: smp@csn.net (Steve Passe) Cc: smp@FreeBSD.ORG, peter@spinner.dialix.com.au, dyson@FreeBSD.ORG Subject: Re: pushdown of "giant lock" Message-ID: <199707162137.OAA01575@phaeton.artisoft.com> In-Reply-To: <199707162025.OAA09649@Ilsa.StevesCafe.com> from "Steve Passe" at Jul 16, 97 02:25:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The following documents a 1st draft proposal for achieving finer-grained > locking. Please comment, paying particular attention to the pseudo-code > I propose for doing it. > > ----------------------------------- cut ----------------------------------- > Proposed 1st cut at "giant lock" pushdown. > > A design proposal for the 1st step in pushing down the "giant lock" (GL) > to achieve finer grained locking. > > --- > Create 3 basic get/rel lock functions from the current get/rel_mplock(). > Each of these supports 3 basic entry types, respectively: > > - getISR_mplock/relISR_mplock: interrupt routines > - getSYS_mplock/relSYS_mplock: system calls > - getTRAP_mplock/relTRAP_mplock: exceptions, traps, etc. > > For the 1st step, each of these 3 variations will behave identically. Their > purpose is to achieve a LOGICAL differentiation. Eventually they will > divert as their needs dictate. The ONLY issue I have with this proposed implementation is "what happens if...": A) getSYS_mplock B) getTRAP_mplock A) getTRAP_mplock << BLOCK B) getSYS_mplock << DEADLOCK This is even more problematic for interrupts, unless each processor has its own kernel stack for interrupts (which poses a number of VM problems which I'm pretty sure you aren't interested in fighting at this time). I think that there is a requirement for: 1) A hierarchical arrangment in which all locks are inferior to a top level lock, such that deadlock conditions can be *avoided* rather than *detected*; there is no clean way to back out state, otherwise. 2) Intention modes should be implemented such that it is not necessary to synchronize locks between processors unless the locks would potentially result in a deadlock 3) There should be the concept of a processor local domain; that is, I would not make an interface distinction between mutexes vs. semaphores at the programmatic interface, but a call should use semaphores where there is no processor contention within a domain. This sets up nicely for per processor resource pools filled from (and drained to) system resource pools. > the object is to allow both MP-safe and MP-unsafe ISR(SYS/TRAP) routines > to co-exist while we transition to a fully MP-safe system. The theory > is that you can allow only 1 MP-unsafe routine in the kernal at any one > instance, but multiple MP-safe routines (IF no MP-unsafe routines are already > in the kernel). The above modifications are a proposal for achieving that > goal. This is a good objective; I don't think my observations make it any less obtainable. I would mopdify it to be "in the kernel on a given processor" in the case where there are per processor kernel stacks for use by ISR's. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707162137.OAA01575>