1. 13
  1.  

  2. 2

    There are only three open-source operating systems in the entire world that really pull it together on having a complete, modern, SMP kernel: Linux, DragonFlyBSD, and FreeBSD.

    Illumos??

    1. 1

      It’s hard to say how the future will develop. There are only three open-source operating systems in the entire world that really pull it together on having a complete, modern, SMP kernel: Linux, DragonFlyBSD, and FreeBSD. And that’s it. We also have NetBSD and OpenBSD and I’d kinda like to know what their plans are, because the future is clearly going not only multi-core, but many-core. For everything. But as I like to say, for SMP there are only three at the moment. One can’t dispute that Linux has nearly all the eyeballs, and DragonFly has very few.

      I like how Dillon throws OpenBSD and NetBSD under the bus w.r.t. real SMP support. What’s the maximum number of cores that DragonFly BSD has ever ran on? What about NetBSD and OpenBSD?

      Of course, performance is a totally different animal than merely hardware support showing hundreds of CPUs in dmesg and top(1). Would be interesting to see any followups confirming or disproving these claims.

      1. 4

        Pretty sure OpenBSD has had giant locks in the network code since smp was first supported (2004-ish?). It improves nearly every release (gets finer grained), but not all gone yet from what I understand. Their focus seems to be more on security over performance though, it should be noted.

        1. 1

          What’s the maximum number of cores that DragonFly BSD has ever ran on?

          At least 48. According to the post, this has been their production build machine for years. There was also a benchmark on 32 core / 64 threads AMD [1]

          Just from a cursory read, I get a feeling that core DBSD dev spend a good amount of time testing/optimizing/experimenting with modern AMD hardware. And this will continue, according to the post.

          Would be good if AMD would support them. Matt D even found an AMD CPU bug [2]

          Their focus on SSD, many-core CPUs, many disks, no-ECC-required hardware platforms, even years back, when those were still exotic, seems to be paying some dividend.

          I originally started follow DBSD because somewhere in their early vision statement, it was talked about Single System Image Clustering (SSI-c) – but 12 years later, I do not think that portion has materialized. [3]

          WRT comment on NetBSD, it seems that NetBSD is well ahead of others (including dbsd) as a platform for Unikernels (rumpkernel) due to NetBSDs long-term vision of modular/abstracted driver subsystem. [4]

          I personally, would like to see ‘specialization’ of OSes more, not less, as long as they are able to maintain and offer compatible OS API (and general-purpose language runtimes .net, .java, c++, d) for us, application developers.

          [1] https://www.phoronix.com/scan.php?page=article&item=dragonfly-55-threadripper&num=1

          [2] https://it.slashdot.org/story/12/03/06/0136243/amd-confirms-cpu-bug-found-by-dragonfly-bsds-matt-dillon

          [3] https://www.dragonflybsd.org/history/

          [4] https://research.csiro.au/tsblog/using-rump-kernels-to-run-unmodified-netbsd-drivers-on-sel4/

          1. 1

            You have the NetBSD Developer hat, so you might know more about how scalable NetBSD is today, how many giant locks are still in place and so on :)

            Honestly, unless something changed like yesterday, my biggest gripe with OpenBSD and NetBSD kernels is that they’re still not tickless. It’s 2019, come on, wasting CPU time when just idling is not cool.

            1. 1

              If there’s something interesting with NetBSD or OpenBSD SMP support he doesn’t know about, tell him. Or us?