Well, NUMA isn't a scheduler. NUMA is a type of SMP configuration. It literally means "Non Uniform Memory Access". Ryzen does seem to be close to a NUMA-type of system, but since the memory controller is shared, things are a bit muddy there. There are two main types of schedulers. CPU schedulers that arrange how your CPUs are "fed" problems to solve, and I/O schedulers that handle input and output in memory and devices of all sorts. The default Linux kernel CPU scheduler is CFS. You can see that if you run: Code: sudo dmesg | grep -i 'cfs' or even better, you can see all of the registered schedulers (CPU and I/O), by running: Code: sudo dmesg | grep -i 'sched' Con Kolivas has a nice comparison about how CPU and I/O schedulers can matter in desktop interactivity (not absolute performance), here. The aim of his patchset is to create a "desktop" system that doesn't go to its knees when heavy I/O is happening, something that has been the Achilles heel of Linux for the desktop since time immemorial. A lot of people also seem to be backing a total rewrite of the I/O subsystem of Linux, aiming to create something like fq_codel (which is a network packet scheduler, and the best -by far, in the business), for normal I/O. This is getting too technical, so let me cut to the chase. 1) NUMA is a type of multi-processor system whose processors have different latencies with some parts of its memory. With Ryzen, all CCX's have the same access times to main memory and I/O, but slower access times to the L3 of the other CPU node. So I would say that this a NUMA system only at a part. The OS CPU scheduler should be smart enough to not switch tasks between CCXs, so that no costly and slow L3 to L3 transfers occur. Ryzen providing 8 whole threads for each CCX should make this trivial. This isn't as hard as it sounds, both Windows and Linux have had this capability for decades now, it just needs to be patched in. 2) CPU governor. This is the program that determines how to clock the CPU depending on workload. The default in Linux is "ondemand", the one I would personally recommend is "performance" or "schedutil". 3) CPU power/frequency driver. That's the driver of the CPU, exposing CPU states to the CPU governor and "taking orders" from the governor. Intel at this point recommends setting the governor to "performance" and letting it's pstate driver do the actual job. AMD has no current driver, just the default ACPI one. 4) The I/O scheduler determines the method used to fetch data from storage devices to the CPU, and move it from it. Wikipedia has a very good diagram on how all this is connected. This one has a tough job as it has to "serve" data from devices that are orders of magnitude slower than the CPU (even RAM and very fast NVMe are much much slower), wait for the CPU to do its thing and then serve it back again. In conclusion, I don't really see Ryzen having any problem if the schedulers are patched. It's inclusion of on-cpu I/O is much more important imo, than the choice to go with a data fabric instead of a ringbus.