That’s Non-Uniform Memory Access, to disambiguate. Matthew Dillon’s changing how memory is allocated in DragonFly. NUMA is been a long-discussed and complex topic for a long time, so I will point at the initial commits and call it “a developing situation”.
3 Replies to “NUMA and DragonFly”
Comments are closed.
What overall impact will this have on performance once completed?
Will this make DBSD more complex or less?
Also, why the change even in the first place?
Speaking in general, as the number of processors in a system increase, you don’t get a linear increase in processing speed/power. This is because you have to manage the resources available to each CPU, so there’s always some overhead. This is, for instance, why the various BSDs had (and to some extent still have) a giant lock system for handling multiprocessor work, because it’s easier to have that lock hold up everything than to attempt to correctly allocate resources.
That’s a general description. In this case, NUMA means that memory allocations are “close” to the processors using that memory, which in a situation where all processors are busy, should reduce that overhead and improve performance.
The short answer is: CPU performance should be improved especially under heavy load on multiprocessor systems, and it won’t make a significant complexity difference, as far as I can tell. This is a complex area that I’ve only had passing exposure to, so don’t treat my explanation as final – but does that help?