Date: Thu, 04 Dec 1997 00:01:22 -0800 From: David Greenman <dg@root.com> To: John Hay <jhay@mikom.csir.co.za> Cc: FreeBSD-current@FreeBSD.ORG Subject: Re: 3.0 -release ? Message-ID: <199712040801.AAA19332@implode.root.com> In-Reply-To: Your message of "Sat, 04 Dec 1997 09:37:57 %2B0200." <199712040737.JAA21468@zibbi.mikom.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >> Perhaps I overstated the issue, I get up times of many weeks on my dual P6 >> >> here that is used as a development system. Obviously many others are also >> >> using SMP for real work. But the efficiency just isn't there yet. We >> >> would bench very poorly against a good SMP system, and thats what needs >> >> improvement b4 we go prime-time with SMP. >> > >> >What about smaller steps? Stabilize the current SMP code and make a >> >release with it (3.0) and then put the next stuff (threaded kernel, >> >removal of the single kernel lock, etc.) in a next release. That >> >way we have shorter release cycles and more people can get exposed >> >to the new features that is currently in -current. I mean, there is >> >nothing that say our first SMP release should be the ultimate one, >> >is there? >> >> Actually, there is, sort of. The problem is that a large number of people >> will be evaluating FreeBSD/SMP when it is released, and if the performance >> sucks, this is what magazine reviewers will say and is what people will >> remember. It's too important of a feature to have working poorly in the >> first release. > >Ok, but how do we measure it, so that we can know when we get there? >(I don't think it is realistic to expect that we will half the time >that make world takes, except maybe if we throw lots of disks and >controllers at it, for instance.) And how bad do we do at the moment? >Things that are more processor intensive than syscall intensive like >rc564, do get almost full speed out of the CPUs, so if that were a >measurement we could ship now. :-) What we have now is pretty bad for just about everything and might actually be slower on a two CPU machine for things that spend their time mostly in the kernel (like Internet servers). There are two things that need to be done: locks need to be pushed down so that we have at least per-subsystem locking (networking, filesystems, VM system, etc), and we need to rewrite the scheduler for process affinity. With those two things working reliably, I would consider the SMP implementation not finished, but releasable as a first cut. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712040801.AAA19332>