[RFC] Added numa_support rfc #1535
Conversation
| Below is the example that demonstrates the use of these APIs to pin threads to different | ||
| arenas to each of the NUMA nodes available on a system, submit work across those `task_arena` | ||
| objects and into associated `task_group`` objects, and then wait for work again using both | ||
| the `task_arena` and `task_group` objects. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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? :)
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
Tests
Documentation
Breaks backward compatibility
Notify the following users
List users with
@to send notificationsOther information