NUMA affinity

[gz]

Not sure this is the right place to ask, but given the already expansive API in the Alloc trait, would specifying a NUMA affinity for allocations also be something that the API could offer? Or is this out of scope?

[TimDiekmann]

Could you elaborate? What is NUMA?

…

On Oct 14, 2019, 03:59, at 03:59, Gerd Zellweger ***@***.***> wrote: Not sure this is the right place to ask, but given the already expansive API in the `Alloc` trait, would specifying a NUMA affinity for allocations also be something that the API could offer? Or is this out of scope? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #29

[Avi-D-coder]

https://www.kernel.org/doc/html/latest/vm/numa.html

[gz]

Sorry for being unspecific with acronyms. I'm talking about non-uniform memory accesses (NUMA).

(Briefly: Server system are often multi-socket machines where the memory access latency is better when a thread on a NUMA node accesses memory that is local to that node)

There are libraries like libnuma that offer the application writer a more explicit interface to control memory allocation by setting the affinity (i.e., which node you want to allocate from) because sometimes default policies like first-touch in Linux may lead to sub-optimal allocations. My question was about if something like this could be part of the Alloc traits too (i.e., as an optional NUMA affinity parameter or separate functions).

[Amanieu]

Is it really necessary to make this part of the AllocRef trait though? If you want to allocate from a specific node in a NUMA-aware allocate, couldn't you just use some sort of builder API to create an AllocRef which only allocates from a particular node?

[gz]

@Amanieu No, I don't think there is anything that prevents to do it the way you describe it. This is just about ergonomics and whether APIs in style of libnuma should be part of the language/Alloc traits.

Please close if this is deemed out of scope.

[gnzlbg]

@gz I tend to think of the first iteration of the AllocRef trait as something that would be useful for the std::collections and Box and it is unclear to me how these collections would be able to use a more complex allocation API portably.

OTOH what @Amanieu suggests allows you to build your own libnuma crate that you can use to create an alloc handle that you can pas to Vec to allocate however you want, and the advantage is that Vec doesn't need any specific code for this.

If you have a particular API in mind for something that the AllocRef trait should expose on all platforms that Rust supports, maybe you could sketch what those APIs would look like ?

[vertexclique]

Would like to mention that I've worked on NUMA affinity and created a NUMA-based allocator already.
https://github.com/bastion-rs/numanji
On top of that I've did quite a lot of work to organize existing context-allocator crate and fixed some possible unsafe problems in it and released as:
https://github.com/bastion-rs/allocator-suite

---

Bastion runtime uses these as unstable API but I am going to work on numanji to take various numa settings.

[alexpyattaev]

NUMA affinity is a must-have on multi-socket server platforms. For a performance-oriented language it is very important to support this. It would enable rust to just outright demolish go on such platforms in memory intensive applications such as databases.