From owner-freebsd-smp Sun Jun 25 10:24:45 2000 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2C48437BAEA for ; Sun, 25 Jun 2000 10:24:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA22733; Sun, 25 Jun 2000 10:24:39 -0700 (PDT) (envelope-from dillon) Date: Sun, 25 Jun 2000 10:24:39 -0700 (PDT) From: Matthew Dillon Message-Id: <200006251724.KAA22733@apollo.backplane.com> To: David Greenman Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Stepping on Toes References: <200006250411.VAA08876@implode.root.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A new SMP patchset is available, bringing it up to date with changes committed -current in recent days (that caused conflicts). This patchset does not yet integrate the alpha patch supplied by Jake Burkholder. (p.s. Jake, was that patch just to make things compile or to make the mutex stuff actually *run* on an alpha?). : Of course we need to wait a few days for people to return from Usenix. I :just got back myself a few hours ago and have over 3000 emails to deal with. :My general view is that we should probably go directly to the threaded :interrupt model and dump spls in the first cut. Given this, I think it would :be prudent to use as much of the BSDI mutex code as possible, at least :for the medium term, since it has been well tested and debugged. Not using :it reaks of NIH to folks on the outside, even though the SMPng group (at :least) knows that that wasn't at all your motivation in rolling your own. : :-DG : :David Greenman Even with interrupt threads we have the GiantMutex issue... the same issue that we have with our current MP implementation. We cannot remove SPL's until we remove the GiantMutex, and we cannot remove GiantMutex without major modifications to just about every single source file in sys/ This is not a trivial job. If we attempt to remove SPLs prior to making the first commit and in tandem with implementing interrupt threads, the result is likely going to be a nightmware disaster (read: months of extra work debugging problems). As much as I like digging into the kernel, I would balk at that (even if I had the time available). The core mutexes (Sched and Giant) and Interrupt threads (both heavy and light weight) are compartmentalizable problems. They can be done piecemeal and thus debugged quite easily alone. If we throw in a thousand other requirements the mess we are going to be left with will be much, much harder to debug. I think the project will go a whole lot faster if we start committing to -current earlier and go through a three-stage process to get to where BSDI is now: * SchedMutex, GiantMutex, spl* compatibility (my patch) ... and commit * Interrupt Threads (Greg) ... and commit * Remove GiantMutex, spl*() replacement (one subsystem at a time) ... and commit, commit, commit Even if you do not wind up using my mutex code (I presume the rest of my patch would be used since I doubt anyone else wants to slog through the interrupt code. It should be easy to separate out the mutex implementation), I still recommend the above three-step process. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message