(no commit message)
authordillon <dillon@web>
Mon, 14 Aug 2017 06:39:46 +0000 (06:39 +0000)
committerIkiWiki <ikiwiki.info>
Mon, 14 Aug 2017 06:39:46 +0000 (06:39 +0000)
features/index.mdwn

index 6920cc4..e3b1074 100644 (file)
@@ -18,6 +18,25 @@ Please keep in mind that major modifications have been made to nearly the entire
 
 * NFS V3 RPC Asynchronization - DragonFly sports a revamped NFSv3 implementation which gets rid of the `nfsiod(8)` threads and implements a fully asynchronous RPC mechanism using only two kernel threads. The new abstraction fixes numerous stalls in the I/O path related to misordered read-ahead requests.
 
+## 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)
 
 ## HAMMER - DragonFly Filesystem