[_kp6z]

I have a huge soft spot for NetBSD because it was my first BSD and first foray into kernel work. The more alarming issue affecting Open and Net is that commodity computer architecture has wildly changed in the past 10 years. A late 1980s style locks and CVs approach to SMP is only good for a handful of cores. Consequently, if you run one of these on what are becoming standard desktop class systems like Ryzen, you are throwing away a great deal of performance (and therefore energy efficiency). Basically modern computers look a lot like an HP SuperDome or whatever from 2000 which is wild and inconvenient for programmers, but reality. FreeBSD (HEAD) is now generally competent on something like an Epyc or multi-socket intel box, and there isn't much left to eek out on an 16-thread laptop.

I funded and helped stabilize a technology called Epoch Reclamation into FreeBSD that can be thought of like a cleaner version of Linux' RCU at least for tracking object liveness. One of the most interesting things I've seen go into FreeBSD recently is a further improvement on that, a novel form of safe memory reclamation directly in UMA: https://reviews.freebsd.org/D22586. This is really exciting because for instance RCU suffers from time of use to time to free issues in Linux, and this new holistic approach really does not for fast turnover workloads.

NetBSD does have a form of SMR called pserialize(9), but ignoring some of the algorithmic weaknesses it also has a lot of global or oversized locks in critical subsystems like the VFS and network stack that turn it into a fairly non-SMP friendly system let alone consideration for different memory latencies like NUMA.

A lot of these ideas from FreeBSD can be copied into Net and Open but the code bases have diverged greatly where it's not some simple forklift (for instance Net and Open use a similar kernel memory allocation that is totally different than Free).