atom feed65 messages in org.freebsd.freebsd-smpRe: SMP meeting summary
FromSent OnAttachments
Jason EvansJun 24, 2000 11:56 pm 
Daniel EischenJun 25, 2000 6:58 am 
Terry LambertJun 25, 2000 10:12 am 
Terry LambertJun 25, 2000 10:36 am 
Julian ElischerJun 25, 2000 10:41 am 
Poul-Henning KampJun 25, 2000 11:07 am 
Nate WilliamsJun 25, 2000 9:41 pm 
Frank MayharJun 25, 2000 11:27 pm 
Frank MayharJun 25, 2000 11:31 pm 
Luoqi ChenJun 26, 2000 9:46 am 
Arun SharmaJun 26, 2000 9:47 am 
Jason EvansJun 26, 2000 11:06 am 
Matthew DillonJun 26, 2000 12:26 pm 
Matthew DillonJun 26, 2000 12:48 pm 
John SconiersJun 26, 2000 12:56 pm 
Matthew DillonJun 26, 2000 1:07 pm 
Luoqi ChenJun 26, 2000 1:13 pm 
Doug RabsonJun 26, 2000 1:26 pm 
Jason EvansJun 26, 2000 2:56 pm 
Jason EvansJun 26, 2000 3:14 pm 
Daniel EischenJun 26, 2000 4:59 pm 
Luoqi ChenJun 26, 2000 7:14 pm 
Jason EvansJun 26, 2000 7:55 pm 
Joe EykholtJun 26, 2000 8:09 pm 
Greg LeheyJun 27, 2000 8:00 pm 
Jason EvansJun 27, 2000 8:25 pm 
Daniel EischenJun 27, 2000 8:26 pm 
Greg LeheyJun 27, 2000 9:59 pm 
Greg LeheyJun 27, 2000 10:11 pm 
Terry LambertJun 28, 2000 4:15 pm 
Terry LambertJun 28, 2000 4:18 pm 
Terry LambertJun 28, 2000 4:37 pm 
Terry LambertJun 28, 2000 4:51 pm 
Arun SharmaJun 28, 2000 9:43 pm 
Greg LeheyJul 2, 2000 7:15 pm 
Daniel EischenJul 3, 2000 3:23 am 
Greg LeheyJul 3, 2000 3:30 am 
Jeroen C. van GelderenJul 3, 2000 7:55 am 
Chuck PatersonJul 3, 2000 8:28 am 
Chuck PatersonJul 3, 2000 8:47 am 
Frank MayharJul 3, 2000 8:49 am 
Greg LeheyJul 3, 2000 4:08 pm 
David ScheidtJul 3, 2000 4:35 pm 
Joe EykholtJul 3, 2000 4:47 pm 
Greg LeheyJul 3, 2000 4:52 pm 
Joe EykholtJul 3, 2000 4:58 pm 
Greg LeheyJul 3, 2000 5:26 pm 
Joe EykholtJul 3, 2000 5:41 pm 
Chuck PatersonJul 3, 2000 7:17 pm 
Daniel EischenJul 3, 2000 7:25 pm 
Daniel EischenJul 3, 2000 7:35 pm 
Greg LeheyJul 3, 2000 7:39 pm 
Daniel EischenJul 3, 2000 7:41 pm 
Chuck PatersonJul 3, 2000 8:40 pm 
Alfred PerlsteinJul 3, 2000 10:08 pm 
Greg LeheyJul 3, 2000 10:37 pm 
Peter WemmJul 4, 2000 2:43 pm 
Greg LeheyJul 4, 2000 3:58 pm 
Peter WemmJul 4, 2000 4:06 pm 
Terry LambertJul 5, 2000 3:38 pm 
Terry LambertJul 5, 2000 4:00 pm 
Terry LambertJul 5, 2000 4:06 pm 
Terry LambertJul 5, 2000 4:10 pm 
Alfred PerlsteinJul 5, 2000 4:29 pm 
Terry LambertJul 6, 2000 4:50 pm 
Subject:Re: SMP meeting summary
From:Greg Lehey (gr@lemis.com)
Date:Jul 4, 2000 3:58:38 pm
List:org.freebsd.freebsd-smp

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

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message