Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems Technology

SMP Now In OpenBSD HEAD 194

Posted by Hemos from the joining-the-core dept.
A number of people dropped e-mails this morning saying that OpenBSD has now got SMP, according to a post from Niklas Hallqvist.
This discussion has been archived. No new comments can be posted.

SMP Now In OpenBSD HEAD More

SMP Now In OpenBSD HEAD

Comments Filter:

  • Hooray! (Score:3, Funny)

    by jb.hl.com ( 782137 ) <<ten.niwdlab-eoj> <ta> <eoj>> on Monday June 14, 2004 @06:27AM (#9418525) Homepage Journal
    Now it can die with super SMP efficiency and at double the speed!

    Just kidding, mods don't hurt me :)

    • Re:Hooray! (Score:4, Funny)

      by turgid ( 580780 ) on Monday June 14, 2004 @06:38AM (#9418552) Journal
      Now it can die with super SMP efficiency and at double the speed!

      Depending on the implementation, it could only be 1.5 times the original speed. In certain special cases, a good implementation might be able to make it die at 2.1 times the speed or greater.

      • Re:Hooray! (Score:1, Funny)

        by Anonymous Coward
        Ahh, heck, 2.1X is nothing--a really bad implementation could just die instantly. :-)

  • userland and config scripts (Score:3, Interesting)

    by tronicum ( 617382 ) * on Monday June 14, 2004 @06:32AM (#9418534)
    I wonder if these CVS changes are enough to support good SMP. At least some userland utilities should support SMP and some of the config scripts that generate make files will probably change (if not autogenerated like automake).

    It would be interesting if it scales well so that it really makes sense to use it. The trend goes to some "double core" CPUs, too...

    • Could you explain what you mean?

      OpenBSD has both a kernel and a userland and this series of merges from the SMP branch (the final one happening this morning) included everything needed to have working SMP. To my knowledge the SMP changes didn't change any user-visible APIs or data structures, so I'm not even seeing why anything in userland would need to be changed.

  • Uh oh, here comes SCO! (Score:5, Funny)

    by Anonymous Coward on Monday June 14, 2004 @06:32AM (#9418536)
    BSD could not have become so popular so quickly without IBM taking the SCO code, putting it in Linux where the BSD people took GPL code put it under BSD license and then.... and anyway, this is based on Minix, because no one person could have written BSD, and AT&T probably would sue them for this anyway. This is hurting american economic... GPL is communistic... and Alex de Tocqueville said that... BSD is dying anyway..

    Oh man. I just give up.

  • SMP defined (Score:2, Informative)

    by Anonymous Coward
    Wikipedia article on Symmetric multiprocessing (SMP) [wikipedia.org].
  • Now I can weld a new proc onto my sparc 5 firewall!
  • Ultimatly all PCs will have to move to multi-processor systems ala G4,G5, so OpenBSD was just making a locical progression that Linux made back in the 2.0 kernel was it? I'm hoping more multiprocessor machines will come out in the future.

    Dispel my ignorence please.

    Does windows have SMP/NUMA support yet?

    Is it economically more feasable to build a multi- (not so great)processor machine rather than a powerful single CPU?

    Thanking (kissing upto) you in advance for the answers.

    • Re: (Score:3, Informative)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
    • Does windows have SMP/NUMA support yet?

      Windows NT has always had SMP support (I think, I haven't used the 3.x series). The workstation version supports 1-2 CPUs, the server ones support more, although they are limited to 16 (I think. Maybe 32. Too lazy to check) due to a the size of the processor table (see Tanenbaum's Modern Operating Systems for more information) Is it economically more feasable to build a multi- (not so great)processor machine rather than a powerful single CPU?

      More or less. Top o


      • yes, Windows NT has had SMP support since 1988, when NT development began. NT also had an O(1) process scheduler since 1988, but Linux likes to accept credit for this "invention" 15 years later..
    • Does windows have SMP/NUMA support yet?

      For over a decade now.

      Is it economically more feasable to build a multi- (not so great)processor machine rather than a powerful single CPU?

      Depends on your objectives and restraints.

  • Great news (Score:3, Interesting)

    by karmawarrior ( 311177 ) on Monday June 14, 2004 @07:15AM (#9418686) Journal
    I know I'm not the only one who's felt that SMP may make or break whether you can efficiently deploy OpenBSD on your workstations and servers. SMP may not be high priority for security, but a secure OS that only gives you access to half the processing power of your system is always going to be a disappointment. And SMP, while not a priority, does help security in that it makes DoS attacks much more difficult.

    (Why? Because many typical DoS attacks work on the basis of a single process hogging the CPU. If you have two, a system administrator can log in and kill the process. If you have one, that system administrator will find it more difficult to do so. It's not a cure-all, but it helps.)

    In all, excellent news. Thanks to everyone who made this possible, regardless of whether you just coded, or you campaigned for support for the OpenBSD project.

    • Actually, the OpenBSD folks held off on SMP support for a while for a good reason.

      Why? Simple. It's a new avenue for bugs and exploits because it makes race conditions more likely to occur. Remember, OpenBSD has a reputation to uphold. ;)

    • many typical DoS attacks work on the basis of a single process hogging the CPU. If you have two, a system administrator can log in and kill the process. If you have one, that system administrator will find it more difficult to do so. It's not a cure-all, but it helps.

      Well then, why not have a 128 processor system, so when 127 processes are tying up a processor a piece, you can still log-in and kill them...

      SMP should not be used as an alternative to failover, and not as a half-assed fix for DoS issues.

      Got

  • Not so fast... (Score:4, Interesting)

    by tqbf ( 59350 ) on Monday June 14, 2004 @07:27AM (#9418738) Homepage

    The initiative to ADD SMP to OpenBSD (and the announcement that "a full time developer was working on it") occurred less than 4 months ago [slashdot.org]. It took FreeBSD years to get SMP "right", during an adolesence where stability seriously suffered.

    Neither NetBSD nor OpenBSD have a significant fraction of the user base of FreeBSD (and an infinitessimal share compared to Linux), and neither NetBSD nor OpenBSD have comparably-sized development teams. FreeBSD SMP had antecedants to build on as well. So logic dictates that it should take longer for OpenBSD SMP to be "ready".

    OpenBSD went through a comparable architecture change when they swapped virtual memory systems a few years ago, and several subsequent major releases of OpenBSD had serious VM stability problems (many of them synchronization issues). SMP is even harder (and more of it involves synchronization).

    So, is there some mitigating factor here that would convince anyone who was paying attention to deploy a mission-critical system on SMP OpenBSD in 2004?

    • Re:Not so fast... (Score:2, Informative)

      by cubidou ( 569514 )

      Since OpenBSD SMP support is mostly NetBSD's plus code style changes, I'd say it only took 4 months to import what was started 3 or 4 years ago by Bill Studenmund for NetBSD.

      Credit where it's due.

      • Re:Not so fast... (Score:4, Informative)

        by cubidou ( 569514 ) on Monday June 14, 2004 @07:39AM (#9418784)
        Since OpenBSD SMP support is mostly NetBSD's plus code style changes, I'd say it only took 4 months to import what was started 3 or 4 years ago by Bill Studenmund for NetBSD.

        Oh, and I forgot, removal of all ACPI code, too.

        That means OpenBSD won't work with MP computers that have a broken MPBIOS or simply require MPACPI (like most, if not all, HyperThreading processors do).

        • That means OpenBSD won't work with MP computers that have a broken MPBIOS or simply require MPACPI (like most, if not all, HyperThreading processors do).

          If you'd read more of the archives linked from the article you would have seens that they are working on it at the Hack-a-thon.

          Also as I'm sure you know, most of the work in implementing an SMP system is not in writing lock.c but in going through the entire OS code (which for Open looks only kinda-sorta like Net at this point) and using the lock and de

    • Re:Not so fast... (Score:2, Informative)

      by Nimrangul ( 599578 )
      So, is there some mitigating factor here that would convince anyone who was paying attention to deploy a mission-critical system on SMP OpenBSD in 2004? If you see it in the 3.6 release, consider it ready. If you don't then it wasn't ready yet.

    • NetBSD nor OpenBSD have comparably-sized development teams [compared to Linux]

      That's not as accurate as you might think. If you look at Linux kernel development, there is a core of really talented developers who work on the guts - the VM system, VFS, threading, etc. Most other people only poke away at the edges, driver writing for instance. If you compare the number of core developers working on Linux and the NetBSD kernel, a similar number of names crop up with regularity on the relevant mailing lists.

    • Re:Not so fast... (Score:3, Insightful)

      by evilviper ( 135110 )

      OpenBSD went through a comparable architecture change when they swapped virtual memory systems a few years ago, and several subsequent major releases of OpenBSD had serious VM stability problems

      I was using OpenBSD at the time, and never had the problems myself. I wasn't following the mailing lists, so I didn't even know there were serious problems.

      So, is there some mitigating factor here that would convince anyone who was paying attention to deploy a mission-critical system on SMP OpenBSD in 2004?

      Yes.

  • soekris (Score:5, Insightful)

    by curator_thew ( 778098 ) on Monday June 14, 2004 @07:51AM (#9418858)

    Read the soekris [soekris.com] website, it puts it nicely:

    FreeBSD The most powerful x86 open source Unix OpenBSD The most secure open source Unix available NetBSD The most portable open source Unix available Linux The most popular open source Unix

  • OpenBSD needs SMP (Score:2, Insightful)

    by Sloppy ( 14984 ) *
    I'm glad they're doing this. I know OpenBSD's focus isn't performance, but the day is coming when all personal computers will be multiprocessor. Not because people will actually put two chips on all their motherboards, but because of dual-core chips. Dual-core is such a great idea that pays off with so much performance per area-of-silicon, that eventually [speculation follows] economy-of-scale is going to make single-core chips an endangered species. Maybe you'll still be able to get a single-core x86 c
  • The strength of BSD over linux has been stability, maturity and predictibility. Linux has more features than any OS out there, and BSD has been a humbler, older, more serious OS with its developers looking less at the market and more at the buglist.

    Of the BSDs, OpenBSD has been the most BSD of them all. FreeBSD is itself a bit of a Linux, slackware to be precise. It has enough 'features' to be usable on most hardware, highly ported, yet strong and reliable too. OpenBSD however has been the simplest, aiming
  • I can do several things at once. I guess I've had SMP in my HEAD for some time now.

Slashdot Top Deals

Adding features does not necessarily increase functionality -- it just makes the manuals thicker.

Close