OpenBSD SMP In The Works

Cajal writes "Four students at the University of Waterloo are working to add SMP support to OpenBSD as part of the Spinlocks project. More information is available in a story at the OpenBSD Journal's site. They expect to have an initial working MP kernel in January."

Comments

Maybe now..

[FuzzyMan45]

They can increase their userbase to (hopefully) include some of the larger companies and corporations that opt to use FreeBSD because of it's SMP support and greater performance than OpenBSD. Hopefully, this modification will also include some performance modifications so it can also compete speedwise with FreeBSD.

While security takes precedence over performance in my book, there are definitely some things that need the performance of FreeBSD.

This is one feature i've been looking forward to playing with (not NEEDING) for a while, i can't wait to try it when it's available somewhere.

--Fuzz

Re:Not to be trollish....

[Anonymous Coward]

Theo and the crew were working on matters they consider more important, like making certain the existing code is robust, secure, and correct.

I guess they can forget about...

[Jacco de Leeuw]

... ever working for Microsoft then!

Microsoft has been raiding the University of Waterloo for programmers for years now.

XP and Linux comparisons are pointless

[flinxmeister]

I've been using OpenBSD in several mission critical networking roles for 3 years now, and I can safely say that I haven't needed SMP.

The conventional wisdom that an operating system should be judged according to it's bells and whistles is what's wrong with the software industry. An OS should be judged by two things: Does it do the job I require of it, and does it do it well?

There are many many jobs that do not require SMP. There are many many jobs being done on SMP boxes that do not require SMP. As the price of processors has diminished, SMP is just a cool thing to buy. I'd be willing to put money down saying that 75% of the SMP boxes out there aren't needed (if that was measurable).

So, if you want to judge your OS based on features you don't need, then go for it. I use OpenBSD because it is the best choice for that particular need. If you want to assume that one OS is the Uber-OS because of the back panel of the box, then go for it. I'll assume a particular OS is best for the task at hand, and go with that.

I'm not part of the OpenBSD project (nor do I play one on TV), but one of the central points behind it is that they don't put in things unless they are needed. So far it doesn't seem like SMP has been justified in the great scheme of things (no surprise given the actual need in the wild). I'd much rather have them working on things I'm going to be using instead of evaluating other products based on things I won't.

Re:XP and Linux comparisons are pointless

[Doomdark]

Yeah, just like Windows users were saying around '95, "who needs pre-emptive multitasking, I've never needed more than co-operative multitasking" (and Mac users until Mac Os X). Or linux users wondering why one needs a journaling file system, up until three of them get mature enough. And when the system does get what was formerly denounced as "unnecessary toy", it suddenly becomes indispensable commodity.

Now, SMP is not necessarily something people "start needing"; you don't usually realize one day that "gee, now I really need SMP". For many things it isn't strictly required, like you say -- after all, most systems only scale up decently to 4- or perhaps 8-way systems, and common rule of thum is that you get about sqrt(num_procs) output (assuming you get enough CPU load for all processors)... and so you can same amount of work done by getting twice as fast CPU (instead of 4-way SMP system).

However, having SMP capability as an option is a Good Thing. For servers it allows nice high-end scalability (esp. with Sun boxes, E10K and co. wouldn't rock if it wasn't their SMP-scalability coupled with kickass I/O.. but those beast scale well past 8 CPUs). For desktop systems it allows for better interactivity (especially on traditional unix[ish] system that have batch-job oriented scheduling), smoother UI.

Very smart...

[Dahan]

Good to see that they're using NetBSD as a reference for this... OpenBSD is basically a less-active branch of NetBSD from a couple years back, so it should be a pretty straightforward process to merge in the SMP stuff from NetBSD (which, like just about every other OS, has had SMP for quite some time now).

OpenBSD is a very promising OS, and SMP support will finally let it play with the big boys in the free *nix playground :)

Re:Very smart...

[LizardKing]

OpenBSD may have been branched from NetBSD, but there is practically no resemblance left anymore. Both, in source code and userland, there have been so many changes that the differences between Net and Open are bigger than the difference between either of them and FreeBSD.

I applaud your attempt to counter the accusation that OpenBSD is "less active" than Net, but you've got it a little wrong. The userland between the three *BSDs is very similar, and the kernels have similar subsystem layouts. Without this similarity, things like softdeps, systrace and IPv6 wouldn't have percolated so quickly into all three. Finally, note that this new OpenBSD SMP work builds on Bill Studenmunds NetBSD code.

Chris

This would be nice

[QuietRiot]

I'm curious how much of a rework will be required [by the OpenBSD core developers] once these guys are done. 4 guys on a one-year project. SMP. Good luck. Will this be a patch-type thing? Will the core team accept it, or reject it outright? Will the core team use some portion of it - cleaning it up along the way, or will it take a major rewrite?

It's strange how things like this end up changing would would have been. Do it right the first time, because if it gets adopted, and it wasn't done right, efforts will be diluted.

I'm glad to see it's happening though. At least somebody's throwing some brainpower at it rather than waiting around for Theo & friends. (no fault to Theo, I know SMP is "in the works" - OpenBSD is secure, first and foremost. That's what I, and many others, care about most. Kudos to you and your team on this! You have a highly-regarded, ultra secure OS that has kept many cracker-types and script-kiddies at bay for many years. You have saved many people many thousands or millions of dollars with the protection your software project has provided. You have given nothing to the headache medicine providers of the IT industry.)

One more processor for my dual-capable Sun SS20 and I'll have a grand-ole time playing with this. Just too bad it comes with only a single 10-speed ethernet port. Anybody know about S-bus fast ethernet cards?

To these brave deveopers: Way to go! Thanks for getting the ball rolling and best of luck with your project (and dealing with the publicity! :)

Re:a bsd question

[Walterk]

Here's something more compact:

"FreeBSD has tcsh installed as /bin/csh. OpenBSD and NetBSD don't. NetBSD runs on a Cobalt Qube2. OpenBSD and FreeBSD don't. OpenBSD can encrypt swap. NetBSD and FreeBSD don't."

Can't remember where I picked that one up.

Re:Hooray!

[jpmorgan]

Part of the problem with security with respect to SMP isn't just the kernel. Many subtle race conditions that could result in security flaws are more likely to be exploitable in a truely parallel environment than they are in just a concurrent uniprocessing environment.

In addition to just making sure the kernel has it right, you've got to make sure that it's not going to open up any holes in the userspace too.

Re:It's about friggin time they did...

[aridhol]

Possibly he wasn't keen on the time investment required to implement SMP. If these guys do all the work, it may well make it in.

OTOH, it may be that SMP code is more difficult to audit, and that this is the reason it won't make it in. Remember, SMP allows for the possibility of race conditions within the kernel itself, which would be a nightmare to validate for security.

Re:a bsd question

[kjd]

Three different projects with separate ideals and goals. Their code has not been "one" for a long time, but code is quite often swapped between the projects in large chunks where deemed useful and possible. Merging the three codebases is really not necessary, as they give and take each other's code as they please; and merging the focus and direction of the three projects would be plenty more difficult than the code. :)

Also, keep in mind that these projects did used to be one. They're now three for many good reasons.

Re:It's about friggin time they did...

[psxndc]

Well if worse comes to worse, they could always fork OpenBSD like Daren Reed did to include ipf. Of course then you lose the trustyworthyness of OpenBSD because it is no longer A) official or B) going under the microscope like OpenBSD does by the OpenBSD team.

psxndc

Support will far outpace other BSDs

[Theo DeRaadt]

As OpenBSD is already the most secure OS available, it's no wonder that we have some of the top scientists in Canada working on bringing in SMP support. We would have taken a ton of code from FreeBSD, but we believe that their upcoming implementation is inferior to what we could come up with on our own. Besides, there's no telling what kind of glaring security holes there could be in FreeBSD's SMP implementation.