Greg Lehey wrote:

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. 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.

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. Once we have something that runs and doesn't panic in 3 seconds, then we have something to tune/optimize/ reimplement/whatever. If we all dive in and invent our own stuff right from the start, we will have just as much pain and suffering as the BSDI folks had and it will take just as long (or longer).

Cheers, -Peter

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