Excuse me what ? If this is really true, why isn't it more widely adopted than Ubuntu for server side deployment ?
then following text is copied from "features" page of official site
>EXTREME SCALING
DragonFly will autotune kernel resources and scaling metrics such as kernel hash-tables based on available memory. The autoscaling has reached a point where essentially all kernel components will scale to extreme levels.
Process and thread components now scale to at least a million user processes or threads, given sufficient physical memory to support that much (around 128GB minimum for one million processes). The PID is currently limited to 6 digits, so discrete user processes are capped at one million, but the (process x thread) matrix can conceivably go much higher. Process creation, basic operation, and destruction have been tested to 900,000 discrete user processes.
File data caching scales indefinitely, based on available memory. A very generous kern.maxvnodes default allows the kernel to scale up to tracking millions of files for caching purposes.
IPI signaling between CPUs has been heavily optimized and will scale nicely up to the maximum hardware thread limit (256 cpu threads, typically in a 128-core/256-thread configuration). Unnecessary IPIs are optimized out, and the signaling of idle cpus can be further optimized via sysctl parameters.
All major kernel resource components are fully SMP-aware and use SMP-friendly algorithms. This means that regular UNIX operations that manipulate PIDs, GIDs, SSIDs, process operations, VM page faults, memory allocation and freeing, pmap updates, VM page sharing, the name cache, most common file operations, process sleep and wakeup, and locks, are all heavily optimized and scale to systems with many cpu cores. In many cases, concurrent functions operate with no locking conflicts or contention.
The network subsystem was rewritten pretty much from the ground-up to fully incorporate packet hashes into the entire stack, allowing connections and network interfaces to operate across available CPUs concurrently with little to no contention. Pipes and Sockets have also been heavily optimized for SMP operation. Given a machine with sufficient capability, hundreds of thousands of concurrent TCP sockets can operate efficiently and packet routing capabilities are very high.
The disk subsystem, particularly AHCI (SATA) and NVMe, are very SMP friendly. NVMe, in particular, will configure enough hardware queues such that it can dispatch requests and handle responses on multiple cpus simultaneously with no contention.
The scheduler uses per-cpu algorithms and scales across any number of cpus. In addition, the scheduler is topology-aware and gains hints from whatever IPC (Inter-Process Communications) occurs to organize active processes within the cpu topology in a way that makes maximum use of cache locality. Load is also taken into account, and can shift how cache locality is handled.
The kernel memory manager is somewhat NUMA aware. Most per-cpu operations use NUMA-local memory allocations. User memory requests are also NUMA aware, at least for short-lived user programs. Generally speaking, the scheduler will try to keep a process on the same cpu socket but ultimately we've determined that load balancing is sometimes more important. CPU caches generally do a very good job of maximizing IPC (Instructions Per Clock). Because memory management is fully SMP-aware, a multi-core system can literally allocate and free memory at a rate in the multiple gigabytes/sec range.
Generally very high concurrency with very low kernel overhead. The kernel can handle just about any load thrown at it and still be completely responsive to other incidental tasks. Systems can run efficiently at well over 100% load.
Supports up to 4 swap devices for paging and up to 55TB (Terabytes) of configured swapspace. Requires 1MB of physical ram per 1GB of configured swap. When multiple swap devices are present, I/O will be interleaved for maximum effectiveness. The paging system is extremely capable under virtually any load conditions, particularly when swap is assigned to NVMe storage. Concurrent page-in across available cpus, in particular, works extremely well. Asynchronous page-out. Extended filesystem data caching via the swapcache mechanism can operate as an extended (huge) disk cache if desired, and/or used to increase the apparent total system memory.
For that to be impressive to me, I also want to know how Linux compares. I suspect that for most non-synthetic workloads, Linux will perform about as well. I may be absolutely wrong -- but my gut feeling is Linux is really good at scaling as well, and has a lot more "real world use" sitting behind it, with a lot more paid engineers fine-tuning it to perform well with actual workloads.
That's why most people aren't going to use Dragonfly over Ubuntu when they're deploying their servers.
> a lot more paid engineers fine-tuning it to perform well with actual workloads.
Just because it is / can be fine-tuned for the workloads of those engineers' employers doesn't mean it is fine-tuned for your loads.
If you're running your servers hard, you probably might considering pay engineers to fine-tune your system. There's certainly room in both FreeBSD and Linux for improvements, depending on what your servers are doing; I'd assume Dragonfly is in the same boat. I may be biased from work experience, but IMHO, the FreeBSD can feel a bit more organized and easier to tinker with; FreeBSD having a kernel debugger certainly helps a lot with some things. If you had infinite resources, you'd run some of your servers on Linux and some on FreeBSD (and maybe some on a purpose built OS just for you, but that requires a large value of infinite resources), and when one does some things better, you can pull ideas back and forth as needed to get all things working better. Of course, some ideas are harder to pull back and forth, and sometimes small differences in ideas make for large differences in results.
For a lot of use cases, the kernel / OS doesn't make a huge contribution to overall performance. As long as you don't use something tragically bad, it'll be fine. There's a pretty narrow set of circumstances where the kernel is the limiting factor, and I say that having spent quite some time working on problems where the kernel was the limiting factor.
> For a lot of use cases, the kernel / OS doesn't make a huge contribution to overall performance. As long as you don't use something tragically bad, it'll be fine.
This is what I was thinking, but did a poor job communicating. I think that Linux, because of all the work poured into it, will usually be good enough. Even though its been less meticulously constructed than DFly and didn't have as much forethought put into picking low overhead SMP algorithms and data structures and what not, in the end, the differences between Linux and DFly in performance will be pretty minimal.
So when faced with using a strange and novel platform with software incompatibilities and possibly a slight performance gain in certain situations, or using the familiar, most people will pick the familiar, and for justifiable reasons IMO.
> So when faced with using a strange and novel platform with software incompatibilities and possibly a slight performance gain in certain situations, or using the familiar, most people will pick the familiar, and for justifiable reasons IMO.
Yep, that's why I stick with FreeBSD :P I don't really want to learn a new tool for ifconfig or netstat. I'd make a joke about three firewalls, but ;)
> Excuse me what ? If this is really true, why isn't it more widely adopted than Ubuntu for server side deployment ?
As great and fun as single image clustering is, it's a pretty niche use-case. Event joyent/smart-os, which went the "other, sensible way", focusing on co-location of storage and processing - turned out to be pretty niche.
Linux had openMosix - didn't see much use outside actual clusters.
If you're not doing the smartos thing, but want full-on ssi - you really (today) need pretty extreme interconnect (ie: infini band or better; high bandwidth, low latency) - every node in you supercomputer needs reasonable access to storage.
The dragonfly people have been working hard on this for years, they've come a long way. But you don't really need it if your workload runs on less than a rack full of servers.
> The kernel can handle just about any load thrown at it and still be completely responsive to other incidental tasks. Systems can run efficiently at well over 100% load.
That's is one really big point especially for DFly but also the other BSD's, having a BSD's at over 150% is not a problem, with linux you try never go over 80-85% if you still want a responsive system. Same with near out of memory, linux handles that really poorly.
i once tried installing and running an openbsd system with 64mb of ram.
It "worked" in the sense that the installation was able to finish, and i was able to run a static webpage on openbsd httpd.
system load was through the roof, but the system was still r esponsive. I started running into issues once i wanted to do anything even slightly more advanced (like for instance, run PHP on a webpage).
Why wouldn't it be true? It's not as if the source and images aren't available for you to look at for yourself.
As for why BSD isn't more popular than Linux, well, that's a much bigger question. It could come down to licensing, project goals (not winning popularity contests), but mostly decades of history and Linux appearing at the right place, at the right time. There is place for alternative operating systems, choice is important.
I have some interest in DragonflyBSD and BSD ethic is close to me, but I'll say that Linux being GPL made it successful. It centralizes development and with every developer joining in it cements it even further. But right place and time above all, if it would start today the license would be a nonstarter for many.
> Linux being GPL made it successful. It centralizes development and with every developer joining in it cements it even further.
Centralization doesn't have much to do with the GPL. With a BSD system, you can take an upstream release and use it as the base of your system and not publish your changes. With a GPL system, you can do the same, but if you distribute your system to others, you have to publish your changes; but you don't have to work with the upstream system unless you want to; your changes might get pushed upstream by someone else, or used as inspiration by upstream, but that's not that common. If you wanted to work with upstream, you can do that with BSD as well.
It may be forgotten or not known by many, but there was a 1991 lawsuit from AT&T over code in BSDi and the code in question was in other BSD distributions at the time including FreeBSD until the 2.0 release in November 1994. Certainly Linux had its moment of legal uncertainty that turned out fine, but it came after it was already well established. BSD had a legal shadow at a much earlier time, and that may have driven some people away.
If PHP supported containers and Haskell didn't -- though we all know Haskell's `jails` feature is absurdly better in all respects, and all white-coated CompSci PhDs know it.
* GPL license (until PHP4)
* evolutionary
* has warts
* pragmatic
* gets shit done
* everyone uses it
* lots tips online (good and bad)
* you have crazy idea, too late, it has already been done
BSD/Haskell
* BSD license
* designed
* elegant
* by the book
* theoretically correct
* nobody uses it
* read the man pages
* you shouldn't do that
probably more, maybe something about globals vs jails/monads. Many of these things stems from evolutionary vs designed.
Because as synthetic benchmark numbers go they are pretty pedestrian. 256 CPU threads? Red Hat claims to support up to 8192 CPU threads in RHEL8. Same for any of the other specific number they call out Linux's synthetic benchmark numbers are much higher.
then following text is copied from "features" page of official site
>EXTREME SCALING
DragonFly will autotune kernel resources and scaling metrics such as kernel hash-tables based on available memory. The autoscaling has reached a point where essentially all kernel components will scale to extreme levels.
Process and thread components now scale to at least a million user processes or threads, given sufficient physical memory to support that much (around 128GB minimum for one million processes). The PID is currently limited to 6 digits, so discrete user processes are capped at one million, but the (process x thread) matrix can conceivably go much higher. Process creation, basic operation, and destruction have been tested to 900,000 discrete user processes.
File data caching scales indefinitely, based on available memory. A very generous kern.maxvnodes default allows the kernel to scale up to tracking millions of files for caching purposes.
IPI signaling between CPUs has been heavily optimized and will scale nicely up to the maximum hardware thread limit (256 cpu threads, typically in a 128-core/256-thread configuration). Unnecessary IPIs are optimized out, and the signaling of idle cpus can be further optimized via sysctl parameters.
All major kernel resource components are fully SMP-aware and use SMP-friendly algorithms. This means that regular UNIX operations that manipulate PIDs, GIDs, SSIDs, process operations, VM page faults, memory allocation and freeing, pmap updates, VM page sharing, the name cache, most common file operations, process sleep and wakeup, and locks, are all heavily optimized and scale to systems with many cpu cores. In many cases, concurrent functions operate with no locking conflicts or contention.
The network subsystem was rewritten pretty much from the ground-up to fully incorporate packet hashes into the entire stack, allowing connections and network interfaces to operate across available CPUs concurrently with little to no contention. Pipes and Sockets have also been heavily optimized for SMP operation. Given a machine with sufficient capability, hundreds of thousands of concurrent TCP sockets can operate efficiently and packet routing capabilities are very high.
The disk subsystem, particularly AHCI (SATA) and NVMe, are very SMP friendly. NVMe, in particular, will configure enough hardware queues such that it can dispatch requests and handle responses on multiple cpus simultaneously with no contention.
The scheduler uses per-cpu algorithms and scales across any number of cpus. In addition, the scheduler is topology-aware and gains hints from whatever IPC (Inter-Process Communications) occurs to organize active processes within the cpu topology in a way that makes maximum use of cache locality. Load is also taken into account, and can shift how cache locality is handled.
The kernel memory manager is somewhat NUMA aware. Most per-cpu operations use NUMA-local memory allocations. User memory requests are also NUMA aware, at least for short-lived user programs. Generally speaking, the scheduler will try to keep a process on the same cpu socket but ultimately we've determined that load balancing is sometimes more important. CPU caches generally do a very good job of maximizing IPC (Instructions Per Clock). Because memory management is fully SMP-aware, a multi-core system can literally allocate and free memory at a rate in the multiple gigabytes/sec range.
Generally very high concurrency with very low kernel overhead. The kernel can handle just about any load thrown at it and still be completely responsive to other incidental tasks. Systems can run efficiently at well over 100% load.
Supports up to 4 swap devices for paging and up to 55TB (Terabytes) of configured swapspace. Requires 1MB of physical ram per 1GB of configured swap. When multiple swap devices are present, I/O will be interleaved for maximum effectiveness. The paging system is extremely capable under virtually any load conditions, particularly when swap is assigned to NVMe storage. Concurrent page-in across available cpus, in particular, works extremely well. Asynchronous page-out. Extended filesystem data caching via the swapcache mechanism can operate as an extended (huge) disk cache if desired, and/or used to increase the apparent total system memory.