[RFC] Added numa_support rfc

[vossmjp]

Description

Adds RFC for simplified NUMA support

Fixes # - issue number(s) if exists

Type of change

Choose one or multiple, leave empty if none of the other choices apply

Add a respective label(s) to PR if you have permissions

• bug fix - change that fixes an issue
• new feature - change that adds functionality
• tests - change in tests
• infrastructure - change in infrastructure and CI
• documentation - documentation update

Tests

• added - required for new features and some bug fixes
• not needed

Documentation

• updated in # - add PR number
• needs to be updated
• not needed

Breaks backward compatibility

• Yes
• No
• Unknown

Notify the following users

List users with @ to send notifications

Other information

[akukanov]

I think the code can be made simpler with std::thread per NUMA domain, instead of relying only on TBB. On the one hand, it also signals that TBB lacks high-level NUMA APIs. On the other hand, TBB, and task arenas specifically, were designed to work well with application level threads where it makes sense. I think it is much better to assume/suggest each NUMA aware arena to be used by a special application thread than to add extra levels of complication with task groups.

[vossmjp]

This pattern of task_arenas and task_groups is what we show in our documentation: for example here. And, probably as a consequence, a pattern we see in applications that use NUMA constraints.

[akukanov]

So, the documentation shows a suboptimal pattern then. In particular, it does not explicitly set the number of reserved slots to 0, and essentially can lead to undersubscription. Why repeating the same mistake one more time? :)

[aleksei-fedotov]

A few typos to fix.

[akukanov]

I would probably call it "Improved NUMA support".
Correspondingly, the RFC folder could be numa_support_improvements, meaning that NUMA support is a core feature and improvements are the gist of the proposal.

[aleksei-fedotov]

As far as I understand the whole numa_support_improvements or simplified_numa_support directory will be moved to rfcs/supported directory once these improvements are accepted. There may be another set of NUMA improvements in the future which could result in another numa_support_improvements directory be created in the same place. And then, when this new set is again accepted, it moves to the same directory. I see potential naming clash issue... It is not related to naming of this directory, but to the naming approach in general. Surely, we could use numa_support_improvements2 as the name of the new directory, but I believe we can do better from the very beginning.

I propose having the directory with the name related to the feature itself, e.g., numa_support, without additionals such as simplified or improvement. This way we will convey the idea that the documents inside directly affect the support of a particular feature. For resolving naming clashes I propose having the file to be named as precise as possible to what the proposal changes avoiding general terms/adjectives such as improved, increased, etc.. For example, for sub-RFC that I wrote, I suggest naming the file to something like introduce_tbbbind_static_library or introduce_tbbbind_statically_linked_with_hwloc; for NUMA-aware allocators name something like introduce_numa-aware_allocator; for task_group dependencies name something like introduce_dependencies_for_tasks_in_task_group; and so on. This way we would avoid name clashing and still this allows grouping similar rfcs together into dedicated folder such as numa_support. Otherwise, I am afraid that the feature is not elaborated enough to be proposed since it sounds too generic in our mind.

[vossmjp]

I will move to a numa_support directory and change title to "NUMA support"