Date: Wed, 5 Jul 2000 08:29:00 +0930 From: Greg Lehey <grog@lemis.com> To: Peter Wemm <peter@netplex.com.au> Cc: Alfred Perlstein <bright@wintelcom.net>, "Jeroen C. van Gelderen" <jeroen@vangelderen.org>, Daniel Eischen <eischen@vigrid.com>, Jason Evans <jasone@canonware.com>, Luoqi Chen <luoqi@watermarkgroup.com>, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <20000705082900.I94351@wantadilla.lemis.com> In-Reply-To: <200007042144.OAA54160@netplex.com.au> References: <grog@lemis.com> <200007042144.OAA54160@netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 4 July 2000 at 14:44:09 -0700, Peter Wemm wrote: > Greg Lehey wrote: >> On Monday, 3 July 2000 at 22:08:24 -0700, Alfred Perlstein wrote: >>> What sort of interesting is that doing it one way or the other is >>> so similar that in reality the initial implementation doesn't >>> matter, switching from one to the other will be trivial at most, >>> the importance lies in getting one implementation done. >> >> There's a big difference in which implementation we do. The BSD/OS >> implementation works, at least in the BSD/OS environment. Nothing >> else has been written. I think it's very important that we get the >> BSD/OS version up and hobbling before we start redesigning things. By >> the time we've done that, we'll understand the material so much better >> that we'll have a double win (working code and an understanding of how >> to do it better). I'm currently up to my elbows in dead interrupt >> code, and I'm surprised how much I'm learning [wipes mess off arms]. > > A general comment.. It was made very clear at the SMP meeting that > things would have taken a lot less time if they had the "safe but > slower" fallback code available right from the start. I feel that > it is imperative that we implement a minimal-but-functional set of > code that we can trust first and *then* take a shot at the > lightweight interrupt context, and do it in such a way that when > Weird Shit(TM) starts happening that we can easily fall back to the > conservative code so that we can eliminate the optimized lightweight > interrupt contexts from suspicion. Agreed. That's the way I'm going. Is there anything I have said that gives you reason to think I'm advocating something else? > Having the BSD/OS code available as a starting point is a huge help. > We should not have to worry about the mutex or witness code until we > are up and running. For some definition of "worry". > There are truckloads of optimizations that can be done afterwards, > but we must walk first, not run. Doing things conservatively and > safely now with an eye towards later optimization will hopefully > save our sanity. Whatever we can leverage from BSD/OS as a "known > quantity" we should - it will reduce the amount of green or untried > code while we get up to speed. If this means that our SMP work > looks a lot like BSD/OS, then so what? It doesn't have to stay that > way forever. I'm also not advocating change for change's sake. If it turns out that the BSD/OS code is the way to go, then I wouldn't want to change. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000705082900.I94351>