You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if (thread_priority_critical == threads::get_self_id()->get_priority())
data.priority = thread_priority_critical;
essentially makes it impossible to create complex DAGs that spawn sub tasks from parent tasks, when only some of the child tasks are lower priority.
The effect of this check is to make all child tasks HP. In our matrix solver the first row/col block on each diagonal is high priority and the first row/col is handled first, so all tasks are children of it and in turn, all become HP.
Two possible solutions spring to mind
Remove the check so that child tasks are not promoted
Add a new priority between thread_priority_normal and thread_priority_critical which would be thread_priority_high and would give the current task high priority, but not child tasks.
Rename one policy to thread_priority_high_recursive to make it more clear that this is passed on to children
I suspect that I should have been using thread_priority_boost instead of thread_priority_critical right from the start, but had not appreciated the distinction between them regarding child tasks. Either way, some renaming of priorities might make this more clear.
The text was updated successfully, but these errors were encountered:
This enumeration lists all possible thread-priorities for HPX threads.
thread_priority_low
Task goes onto a special low priority queue and will not be executed until all high/normal priority tasks are done, even if they are added after the low priority task.
thread_priority_default
Will assign the priority of the task to the default (normal) priority.
thread_priority_normal
Task will be executed when it is taken from the normal priority queue, this is usually a first in-first-out ordering of tasks (depending on scheduler choice). This is the default priority
thread_priority_boost
Same as thread_high_priority except that the thread will fall back to thread_priority_normal if suspended and resumed.
thread_priority_high
Task goes onto a special high priority queue and will be executed before normal/low priority tasks are taken (some schedulers modify the behaviour slightly and the documentation for those should be consulted).
thread_priority_high_recursive
The task is a high priority task and any child tasks spawned by this task will be made high priority as well - unless they are specifically flagged as non default priority.
Where does thread_priority_boost fit into your new list of priorities? This priority gives a thread high priority on the first invocation, however it falls back to normal priority if suspended/resumed.
Would you agree to add the following:
thread_priority_boost
Same as thread_high_priority except that the thread will fall back to thread_priority_normal if suspended and resumed.
Debugging problems in performance with our matrix code has revealed that the following check
hpx/hpx/runtime/threads/detail/create_thread.hpp
Lines 76 to 77 in d114fc3
essentially makes it impossible to create complex DAGs that spawn sub tasks from parent tasks, when only some of the child tasks are lower priority.
The effect of this check is to make all child tasks HP. In our matrix solver the first row/col block on each diagonal is high priority and the first row/col is handled first, so all tasks are children of it and in turn, all become HP.
Two possible solutions spring to mind
thread_priority_normal
andthread_priority_critical
which would bethread_priority_high
and would give the current task high priority, but not child tasks.thread_priority_high_recursive
to make it more clear that this is passed on to childrenI suspect that I should have been using
thread_priority_boost
instead ofthread_priority_critical
right from the start, but had not appreciated the distinction between them regarding child tasks. Either way, some renaming of priorities might make this more clear.The text was updated successfully, but these errors were encountered: