From owner-freebsd-current Mon Mar 2 09:29:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12774 for freebsd-current-outgoing; Mon, 2 Mar 1998 09:29:37 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12765 for ; Mon, 2 Mar 1998 09:29:34 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id KAA25803; Mon, 2 Mar 1998 10:29:32 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd025694; Mon Mar 2 10:29:21 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA15934; Mon, 2 Mar 1998 10:29:16 -0700 (MST) From: Terry Lambert Message-Id: <199803021729.KAA15934@usr02.primenet.com> Subject: Re: 3.0-RELEASE? To: smp@csn.net (Steve Passe) Date: Mon, 2 Mar 1998 17:29:16 +0000 (GMT) Cc: opsys@mail.webspan.net, toor@dyson.iquest.net, jak@cetlink.net, current@FreeBSD.ORG In-Reply-To: <199803021654.JAA28772@Ilsa.StevesCafe.com> from "Steve Passe" at Mar 2, 98 09:54:58 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > I think that the *biggest* and most complex thing that will be missing > > > will be the fine-grained SMP. It seems that we'll have ELF support, > > > but I forget (or simply don't know) if we (they) decided that ELF will be > > > primary or not. > > > > I was hoping to see SMP (in ANY form), kernel threads, RAID, and > > softupdates, and maybe some TCP stuff, SACK, etc.. > > But RAID, and SMP, and softupdates isn't bad. > > I know this probably won't be good news for most, but I don't see SMP being > in 3.0: I think if this happens, it would be a good idea to relabel the 3.x branch to be the 2.3 or 2.x (x>2) branch, and reserve 3.0. The point of major revision numbers is major revision. I, for one would not be comfortable taking FreeBSD into the end-of-cycle version range (4.x+). Down that road lies madness and "FreeBSD II". > The state it is in now is NOT release quality. I don't think there is much > finer grained locking to be had without MAJOR changes to the design, > specifically the slpx() stuff needs to be replaced with critical sections > protected by a mutex mechanism. I played around with techniques for > allowing both CPUs into the kernel at the same time with the current > splx() design but it appears to be a loosing proposition. I've been working on a fine grained intention mode lock manager with deadlock avoidance and cycle detection. John Dyson has seen the whiteboard design for the thing. I *don't* think the FreeBSD kernel code is amenable to anything less (such as Djikstra's "Banker's Algorithm") because of the need to hold state over more than one level of function calls. It's likely that it would take a serious redesign of the kernel itself to be able to support a radically different approach, like resource preemption (sorry RealTime fans). You simply can't back the state far enough out for it to work. My research code will unfortunately *not* be baked in time for the aggressive schedule for 3.0 which has been proposed. If someone else who can do mathematical programming wants to take up the torch, I can send my internal design discussons (yes, I document it when I talk to myself 8-)). You should have at least a working undestanding of Linear Algebra and Group Theory (math proceeds from Group Theory to Tensor Calculus to Graph Theory) and/or Clifford Algebra's (from which you can get geometric soloutions without Tensors). If you know what "Warshal's Algorithm" and "A Hamiltonian cycle" are, then you probably qualify. Unfortunately, the best non-heavy-math soloution is O(N^3) for N locks; this is simply not good enough for fine grain locking (which will result in a larger number of locks being needed, the finer the grain). > My suggestion (assumming no new major push REAL SOON) is to remove the > SMP support from 3.0 and make a release out of it (when all other things > are ready). Then continue SMP efforts in 4.0 At the very least the > experimental things defined in smptests.h need to either be incorporated > as default (most everything but PUSHDOWN_LEVELs 3 & 4), or removed > entirely ie. PUSHDOWN_LEVELs 3 & 4. These are my above mentioned attempts > to allow both CPUs in simultaniously. Its ugly code, and will never > be 'right'. I think whatever is released should support low granularity SMP, at the very least. I would be *very* unhappy with having to bump the version number to 4.0 in the process (it implies too long a time frame, and it's frankly too large a number to allow the software to appear trustworthy, IMO. Cv: SVR4). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message