|
StarPU Handbook
|
StarPU's Modularized Schedulers are made of individual Scheduling Components Modularizedly assembled as a Scheduling Tree. Each Scheduling Component has an unique purpose, such as prioritizing tasks or mapping tasks over resources. A typical Scheduling Tree is shown below.
|
starpu_push_task |
|
v
Fifo_Component
| ^
| |
v |
Eager_Component
| ^
| |
v |
--------><--------------><--------
| ^ | ^
| | | |
v | v |
Fifo_Component Fifo_Component
| ^ | ^
| | | |
v | v |
Worker_Component Worker_Component
When a task is pushed by StarPU in a Modularized Scheduler, the task moves from a Scheduling Component to an other, following the hierarchy of the Scheduling Tree, and is stored in one of the Scheduling Components of the strategy. When a worker wants to pop a task from the Modularized Scheduler, the corresponding Worker Component of the Scheduling Tree tries to pull a task from its parents, following the hierarchy, and gives it to the worker if it succeded to get one.
StarPU is currently shipped with the following pre-defined Modularized Schedulers :
It is currently needed to set the environment variable STARPU_SCHED to use those Schedulers. Modularized Schedulers' naming is tree-*
|
starpu_push_task |
|
v
Fifo_Component
| ^
Push | | Can_Push
v |
Eager_Component
| ^
| |
v |
--------><-------------------><---------
| ^ | ^
Push | | Can_Push Push | | Can_Push
v | v |
Fifo_Component Fifo_Component
| ^ | ^
Pull | | Can_Pull Pull | | Can_Pull
v | v |
Worker_Component Worker_Component
Each Scheduling Component must follow the following pre-defined Interface to be able to interact with other Scheduling Components.
StarPU is currently shipped with the following four Scheduling Components :
Some rules must be followed to ensure the correctness of a Modularized Scheduler :
The following code shows how the Tree-Eager-Prefetching Scheduler shown in Section An Example : The Tree-Eager-Prefetching Strategy is implemented :
Each Scheduling Component is instantiated from a Generic Scheduling Component, which implements a generic version of the Interface. The generic implementation of Pull, Can_Pull and Can_Push functions are recursive calls to their parents (respectively to their children). However, as a Generic Scheduling Component do not know how much children it will have when it will be instantiated, it does not implement the Push function.
A Scheduling Component must implement all the functions of the Interface. It is so necessary to implement a Push function to instantiate a Scheduling Component. The implemented Push function is the "fingerprint" of a Scheduling Component. Depending on how functionalities or properties the programmer wants to give to the Scheduling Component he is implementing, it is possible to reimplement all the functions of the Interface. For example, a Flow-control Component reimplements the Pull and the Can_Push functions of the Interface, allowing him to catch the generic recursive calls of these functions. The Pull function of a Flow-control Component can, for example, pop a task from the local storage queue of the Component, and give it to the calling Component which asks for it.
The Tree-Eager-Prefetching Scheduler shown in Section An Example : The Tree-Eager-Prefetching Strategy follows the previous assumptions :
starpu_push_task
Pump
|
Area 1 |
|
v
-----------------------Fifo_Component-----------------------------
Pump
| ^
Push | | Can_Push
v |
Area 2 Eager_Component
| ^
| |
v |
--------><-------------------><---------
| ^ | ^
Push | | Can_Push Push | | Can_Push
v | v |
-----Fifo_Component-----------------------Fifo_Component----------
| ^ | ^
Pull | | Can_Pull Pull | | Can_Pull
Area 3 v | v |
Pump Pump
Worker_Component Worker_Component