From owner-freebsd-smp Fri Aug 8 15:03:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA17600 for smp-outgoing; Fri, 8 Aug 1997 15:03:30 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA17591 for ; Fri, 8 Aug 1997 15:03:23 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id QAA00511; Fri, 8 Aug 1997 16:03:19 -0600 (MDT) Message-Id: <199708082203.QAA00511@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Poul-Henning Kamp cc: smp@freebsd.org Subject: Re: HEADS UP: programming the SMP kernel In-reply-to: Your message of "Fri, 08 Aug 1997 16:27:41 +0200." <26062.871050461@critter.dk.tfs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Aug 1997 16:03:19 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > >We need to agree on the set of primatives available for coding SMP > >specific kernel code. Along with this we need a concise document describing > >the dos and donts of SMP conforming code. > > I think the right thing to do, is to stand firm on only the documentation > part. > > There are a multitude of locking primitives, and I don't think we should > needlessly limit ourselves to one type, if there are better ones available > for certain purposes. I agree with this in the abstract. But we need to introduce them in an orderly way. If we don't we will have endless grief trying to find deadlocks, etc. Perhaps this is better expressed as: We should start with the locks provided by the lite2 lock manager, and add others as the need becomes obvious. I am much more concerned with expanding to fine-grained locks in a manner that maintains kernel stability than getting the greatest efficiency in the first pass. Once we have gotten to the point where we have pushed the locking down to the granularity we want, we can then evaluate the locking types to see if alternatives make sense. If someone can point out glaring deficiencies in the lite2 lock manager then this is a different matter... --- > Certain operations can be done atomically (twiddle a bit in a word for > instance) and I think we should leave the doors wide open for that kind > of mechanisms too. agreed, atomic data operations where then can be done are great, and I am not suggesting that you do: push $_foolock call _simple_lock add $1, _foodata call _simple_unlock add $4, %esp when: lock inc _foodata will work. This is a topic to the "how-to" document, describing where each would be appropriate. --- > The important thing is to get documented clearly what locking is used > where, what hierarchies of objects&locks exists and some implementations > of the locking primitives that will check this (#ifdef SMP_ANAL_RETENTIVE). agreed. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD