OpenBSD Journal

OpenBSD SMP Project

Contributed by jose on from the multiprocessor dept.

A friend recently pointed me to the Spinlocks project , where four University of Waterloo students are working on adding SMP capabilities to OpenBSD. Rosco Hill sent me a quick status update when I inquired:

our project is still in development. we are doing a re-design because our initial design did not properly account for modifications to pmap. but our kernel is spinlocked, our scheduler is mostly working, and we do expect to complete a MP kernel in january, though its performance will likely not be much better than a UP system until we optimize...

They have some cool stuff up on their site, and it sounds like they're making some progress. It will be interesting to see what comes of this.

(Comments are closed)


Comments
  1. By r0bert () on

    yes! i am looking forward to this!!! my dual-cpu fileserver feels like my wife with only one breast :D

    Comments
    1. By Anonymous Coward () on

      Fileserver? Are you serious? Are you serving 10Gbit network?

  2. By Anonymous Coward () on

    Which will come first, OpenBSD SMP or Duke Nukem Forever?

    Comments
    1. By Anonymous Coward () on

      ROTFL. This is on of the best comments I've ever read!

    2. By Anonymous Coward () on

      Which will come first, OpenBSD SMP or Duke Nukem Forever
      That's a rip-off of a quote I saw on /.

  3. By Joe Gee () mys3lf@mailcity.com on mailto:mys3lf@mailcity.com

    Thank you, thank you, and thank you o noble developers! I have an OBSD mail server that *aches* for SMP. In all seriousness, this is wonderful news. Mr. de Raadt, are you watching? :)

    Comments
    1. By Anonymous Coward () on

      What sort of mail server? Usually, disk I/O bottlenecks on a mail server before CPU. Only mail server I've seen that ached for dual processing capability was a Win2K/E2K box - and that was for striking up the GUI :)

  4. By Sacha () on

    I hope Theo allows this hack CVS access. Knowing Theo it could take some time.

  5. By click46 () click46@operamail.com on mailto:click46@operamail.com

    in all likely hood, when is theo, or anyone else on the project, going to have the time to audit this code? SMP has never been a priority for the project so I highly doubt they'll audit it anytime soon after the release.

    Comments
    1. By Miod Vallat () miod@openbsd.org on mailto:miod@openbsd.org

      Since there is no code released yet, there is nothing to audit.

      Things will happen in time.

    2. By Scot Bontrager () openbsd@indievisible.org on mailto:openbsd@indievisible.org

      When spinlock submits their changes I'll be sending Theo a hefty check with the comment:

      /* cash when SMP becomes a priority */

      I'm sure Theo & crew aren't above accepting cash to influence what's a priority.

      I've been buying a CD every 6 months for 4 years, I get at least 1 t-shirt every year. But the big donations come with the big features. Even half-arse SMP (processes/threads but not kernel scheduled and running on the second processor) will help. Heck, I've even offered to give them a Sparc 690MP if they figure a way to get it from Texas to whoever wants it... (no reply, as with all my other offers of free hardware... odd [who do I have to beat to get them to take my old crap?!]).

      But, I don't want SMP to screw anything else up. I run OpenBSD because it works, properly, all the time (unless I screw it up myself). No feature is worth an unstable system. Ever.

      I'm sure if enough of us send Theo $500USD checks saying "for SMP". He'll get the message.

      Comments
      1. By RC () on

        Send me the checks. Sure, I won't add SMP support, but nothing says that Theo will either.

        If you want SMP, donate an SMP box. That, or actually contract Theo to do the work. Otherwise, he might as well continue NOT working on it, since once it's finished, all those donations will stop.

        Comments
        1. By Anonymous Coward () on

          I hope this doesn't offend the OpenBSD team, but I think that commercial users who want a certain feature can have a win for themselves and for OpenBSD if they contract Theo or other team members to add the feature. So long as the feature is in harmony with the OpenBSD goals, this should be a fine thing to do, right? And in this case (SMP) certainly there is no reason not to have it in OpenBSD, if it is up to standards.

  6. By Dom De Vitto () on

    Minimum changes and maximum comments are the was to get things past Theo - he and Linus are both very serious on stability, especially as MS will jump on the whole thing with $10m in marketing if either of them screws up.

    Getting things past Theo should be hard, as he's built up a trust with those who use Obsd, and to let a big screwup into the kernel would betray that trust.

    Course, if these get it right and don't destabilise the kernel (e.g. by enabling SMP with a kernel option) it would be great...

    Dom

    Comments
    1. By Anonymous Coward () on

      I find it funny that you think Microsoft cares about OpenBSD.

      Comments
      1. By Anonymous Coward () on

        If it can give them money, they'll buy it.

  7. By Anonymous Coward () on

    I hope this makes it into the official distribution (when/if it is up to the quality standards). SMP + Java would mean that OpenBSD can compete with Linux as an "enterprise" (lame word, I know) web server.

    Now with the GEOM disk system being ported, we will finally have a system with incredible stability and network security, plus disk-level security, plus (eventually, I hope) SMP and Java. There's nothing more I could want for a server machine.

    Comments
    1. By Anonymous Coward () on

      Where can I find this GEOM port?

  8. By zil0g () on

    just putting down a vote for SMP, I want it, ASAP :)
    (if only I could code better than a 5yr old I'd do something for it right away)

    Comments
    1. By RC () on

      It's not an easy job even for professionals. Just look at FreeBSD's SMP, which they inherited from BSDi. As of 5.0, FreeBSD SMP is supposedly getting some serious improvements. Maybe after FreeBSD 5.0 would be the time to port SMP...

      Comments
      1. By Anonymous Coward () on

        You may be dead on, but this notion seems to have been pushed around for a couple of years already. It'd be nice to seem something materialize sooner.

  9. By Anonymous Coward () on

    Look at solaris source.

    Comments
    1. By Phreak () phreak@spy.net on mailto:phreak@spy.net

      That makes me so Happy.Thats the only thing Im missing with my OpenBSD toys.

  10. By John Jones () johnjones@postmaster.co.uk on mailto:johnjones@postmaster.co.uk

    is it portable ?

    focus on x86 and sparc what about ARM and MIPS they are what counts

    regards

    John Jones

    Comments
    1. By FullyArticulate () FullyArticulate@yahoo.com on mailto:FullyArticulate@yahoo.com

      I've done OpenBSD ports for both ARM (StrongARM) and MIPS (MIPS32--AMD's Alchemy Au1000 & Au1500). It's pretty easy. As for SMP, MIPS, at least, should be MUCH easier than x86. There is no APIC, there're only two multiprocessor-useful instructions, and MP MIPS processors tend to do a lot of the 'hard stuff' behind the scenes. (Bus sniffing, for example, to ensure coherent caches).

      My x86 knowledge is limited, but once the mach indep stuff is done, I'll be doing a MIPS64 port pretty shortly after.

  11. By Anonymous Coward () on

    http://www.openbsd.org.ua/smp.html

    redundant work?

  12. By Anonymous Coward () on

    I OpenBSD has no more suid/sgid binaries (using privilege elevation) and SMP support, I'll make a donation (can't wait to get Sparc64 SMP support one day), but I know that things will come in time.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]