-
Couldn't load subscription status.
- Fork 116
[oneTBB] Add a function to create a set of NUMA bound task arenas #650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
93dbd8a to
f819fc1
Compare
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
|
@aleksei-fedotov @akukanov Please take a look. |
| .. cpp:function:: std::vector<oneapi::tbb::task_arena> create_numa_task_arenas(oneapi::tbb::task_arena::constraints other_constraints = {}, unsigned reserved_slots = 0) | ||
|
|
||
| Returns a ``std::vector`` of ``task_arena`` objects, each bound to a separate NUMA node. | ||
| The number of created ``task_arena`` is equal to the number of NUMA nodes available on the system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall it be less strict and, thus, more accurate?
| The number of created ``task_arena`` is equal to the number of NUMA nodes available on the system. | |
| The number of created ``task_arena`` is equal to the number of NUMA nodes detected on the system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we require that this is the same set of nodes that is returned by tbb::info::numa_nodes()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is fair to require that as well, since the intent of this API is to provide shortcut to a common usage pattern of NUMA-constrained arenas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the description
Co-authored-by: Aleksei Fedotov <fedotov.aleksei@gmail.com>
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
source/elements/oneTBB/source/task_scheduler/task_arena/task_arena_cls.rst
Show resolved
Hide resolved
source/elements/oneTBB/source/task_scheduler/task_arena/task_arena_cls.rst
Outdated
Show resolved
Hide resolved
source/elements/oneTBB/source/task_scheduler/task_arena/task_arena_cls.rst
Outdated
Show resolved
Hide resolved
source/elements/oneTBB/source/task_scheduler/task_arena/task_arena_cls.rst
Outdated
Show resolved
Hide resolved
Co-authored-by: Alexey Kukanov <alexey.kukanov@intel.com>
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
Co-authored-by: Alexey Kukanov <alexey.kukanov@intel.com>
source/elements/oneTBB/source/task_scheduler/task_arena/task_arena_cls.rst
Outdated
Show resolved
Hide resolved
source/elements/oneTBB/source/task_scheduler/task_arena/task_arena_cls.rst
Outdated
Show resolved
Hide resolved
source/elements/oneTBB/source/task_scheduler/task_arena/task_arena_cls.rst
Outdated
Show resolved
Hide resolved
| the ``task_arena`` objects. The ``numa_id`` value in ``constraints`` is automatically | ||
| replaced with a separate value for each created arena. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The second sentence is not 100% clear for me.
As far as I understand, the numa_id value in constraints is ignored and the corresponding numa_id` from tbb::info::numa_nodes`` is used instead.
May be something like this will be easier to understand?
| the ``task_arena`` objects. The ``numa_id`` value in ``constraints`` is automatically | |
| replaced with a separate value for each created arena. | |
| the ``task_arena`` objects. The ``numa_id`` value specified in ``constraints`` is disregarded, and instead, | |
| the corresponding ``numa_id`` from ``tbb::info::numa_nodes()`` is used during construction | |
| of each particular ``task_arena``. |
Also, should we specify this somehow if the error occurs during the system parsing as part of create_numa_task_arenas()? Will the numa_id be ignored in this case?
I understand that if the error occurs in create_numa_task_arenas, then it is hard to imagine that there is a valid numa_id in constrains, but may be it still make sense to specify the behavior explicitly somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using another value instead of an ignored parameter and replacing that parameter with the other value is essentially the same thing. Either wording does not mandate a specific implementation. The proposed possible implementation (https://github.com/uxlfoundation/oneTBB/blob/master/rfcs/proposed/numa_support/create-numa-arenas.md#possible-implementation) uses the replacement, I would say.
I wanted to avoid words like "ignored" - especially without saying what is used instead. But I can see how this might still be confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it is better to say that the numa_id parameter for constraints will be automatically set to a certain value:
| the ``task_arena`` objects. The ``numa_id`` value in ``constraints`` is automatically | |
| replaced with a separate value for each created arena. | |
| the ``task_arena`` objects. For each created arena, the ``numa_id`` value in ``constraints`` | |
| is automatically set to the corresponding NUMA node ID from ``tbb::info::numa_nodes()``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Applied suggestions from here and in the comment above from the different discussion.
Co-authored-by: Konstantin Boyarinov <konstantin.boyarinov@intel.com> Co-authored-by: Alexey Kukanov <alexey.kukanov@intel.com>
…scovery Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
| } | ||
| for (int i = 0; i < numa_nodes.size(); i++) { | ||
| for (int i = 0; i < arenas.size(); i++) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pattern demonstrates the usage, but it would be better to execute in one task_arena after enqueuing in the others. Since none of the arenas reserve a slot for a master, the main thread might wait on a fully subscribed arena, and so cannot actively participate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remember, it's the specification. The examples here are intended to illustrate usage. In the developer guide, we have a better example: https://uxlfoundation.github.io/oneTBB/main/tbb_userguide/Guiding_Task_Scheduler_Execution.html#set-numa-node
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Content looks good to me. Although, I would also tweak a little representational aspects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, you can't make indentation when using .. cpp::function with line breaks, so at best it will end up like this:
std::vector<task_arena> create_numa_task_arenas(
task_arena::constraints constraints = {},
int reserved_slots = 0)| std::vector<task_arena> create_numa_task_arenas(task_arena::constraints constraints = {}, | ||
| unsigned reserved_slots = 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In other functions, similar parameters are named a bit different. Compare:
-
std::vector<task_arena> create_numa_task_arenas(task_arena::constraints constraints = {}, unsigned reserved_slots = 0)
-
void initialize(constraints a_constraints, unsigned reserved_for_masters = 1, priority a_priority = priority::normal)
I suggest to use reserved_slots and perhaps constraints_ (or maybe a_constraint?) consistently for all functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also change a_priority to priority_ for consistency?
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>



Add a page that describes helper APIs to simplify constrained arena creations. Currently it is a single function
oneapi::tbb::create_numa_task_arenasfrom corresponding RFC.