Date: Mon, 2 Mar 1998 17:29:16 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: smp@csn.net (Steve Passe) Cc: opsys@mail.webspan.net, toor@dyson.iquest.net, jak@cetlink.net, current@FreeBSD.ORG Subject: Re: 3.0-RELEASE? Message-ID: <199803021729.KAA15934@usr02.primenet.com> In-Reply-To: <199803021654.JAA28772@Ilsa.StevesCafe.com> from "Steve Passe" at Mar 2, 98 09:54:58 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803021729.KAA15934>