Date: Mon, 2 Mar 1998 17:31:41 -0500 From: "Alfred Perlstein" <perlsta@cs.sunyit.edu> To: "Terry Lambert" <tlambert@primenet.com>, "Steve Passe" <smp@csn.net> Cc: <opsys@mail.webspan.net>, <toor@dyson.iquest.net>, <jak@cetlink.net>, <current@FreeBSD.ORG> Subject: Re: 3.0-RELEASE? (making an ass out of myself) Message-ID: <040101bd4632$94668de0$0600a8c0@win95.local.sunyit.edu>
next in thread | raw e-mail | index | archive | help
(this is just a wild guess, so laugh as much as you want, but please read) Maybe a KISS approach to smp? (maybe this is the current approach anyway) identify several key functions/actions that can NOT be done at the same time in the kernel. when a function is called a bitmask is checked against the function's resource requirement bitmask. if things are good (the bits aren't set in the mask), the mask is OR'd with function's mask and we proceed, if the bits are "used" at the moment process is blocked until the required bits are available. the function will then have to remove its resource requirement bits from the mask on exit. some general sort of way to migrate a function call from cpu to cpu might be nessesary if some time period has elapsed because we might have A and B taking the required bits from C while A and B are called alternatly. i do agree that for some reason going to 3.0 without SMP sounds kinda bad. perhaps the most stable stuff could be used and nitpicking the design could be left for 4.0. if it isn't too much bother i would love to get a hold of that document Terry is talking about, i do not have the math prerequisite, but then again it would be very interesting. thank you, -Alfred -----Original Message----- From: Terry Lambert <tlambert@primenet.com> To: Steve Passe <smp@csn.net> Cc: opsys@mail.webspan.net <opsys@mail.webspan.net>; toor@dyson.iquest.net <toor@dyson.iquest.net>; jak@cetlink.net <jak@cetlink.net>; current@FreeBSD.ORG <current@FreeBSD.ORG> Date: Monday, March 02, 1998 8:32 AM Subject: Re: 3.0-RELEASE? >> > > 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 > 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?040101bd4632$94668de0$0600a8c0>