Move list of modular schedulers to user documentation

doc/doxygen/chapters/320_scheduling.doxy

@@ -177,6 +177,44 @@ the current consumption in Watt. Multiplying this value by the average duration
 of a single task gives the consumption of the task in Joules, which can be given
 to starpu_perfmodel_update_history().
 
+\section ExistingModularizedSchedulers Modularized Schedulers
+
+StarPU provides a powerful way to implement schedulers, as documented in \ref
+DefiningANewModularSchedulingPolicy . It is currently shipped with the following
+pre-defined Modularized Schedulers :
+
+- Eager-based Schedulers (with/without prefetching : \c modular-eager ,
+\c modular-eager-prefetching) : \n
+Naive scheduler, which tries to map a task on the first available resource
+it finds.
+
+- Prio-based Schedulers (with/without prefetching :
+\c modular-prio, \c modular-prio-prefetching) : \n
+Similar to Eager-Based Schedulers. Can handle tasks which have a defined
+priority and schedule them accordingly.
+
+- Random-based Schedulers (with/without prefetching: \c modular-random,
+\c modular-random-prio, \c modular-random-prefetching, \c
+modular-random-prio-prefetching) : \n
+Selects randomly a resource to be mapped on for each task.
+
+- Work Stealing (\c modular-ws) : \n
+Maps tasks to workers in round robin, but allows workers to steal work from other workers.
+
+- HEFT Scheduler : \n
+Maps tasks to workers using a heuristic very close to
+Heterogeneous Earliest Finish Time.
+It needs that every task submitted to StarPU have a
+defined performance model (\ref PerformanceModelCalibration)
+to work efficiently, but can handle tasks without a performance
+model. \c modular-heft just takes tasks by priority order. \c modular-heft takes
+at most 5 tasks of the same priority and checks which one fits best. \c
+modular-heft-prio is similar to \c modular-heft, but only decides the memory
+node, not the exact worker, just pushing tasks to one central queue per memory
+node.
+
+To use one of these schedulers, one can set the environment variable \ref STARPU_SCHED.
+
 \section StaticScheduling Static Scheduling
 
 In some cases, one may want to force some scheduling, for instance force a given

doc/doxygen/chapters/350_scheduling_policy_definition.doxy

@@ -173,70 +173,6 @@ unique purpose, such as prioritizing tasks or mapping tasks over resources.
 A typical Scheduling Tree is shown below.
 
 <pre>
-                                  |
-              starpu_push_task    |
-                                  |
-                                  v
-                            Fifo_Component
-                                |  ^
-                           push |  |  pull
-                                v  |
-                           Eager_Component
-                                |  ^
-                           push |  | pull
-                                v  |
-                 --------><--------------><--------
-                 |  ^                          |  ^
-            push |  | pull                push |  | pull
-                 v  |                          v  |
-             Fifo_Component                 Fifo_Component
-                 |  ^                          |  ^
-            push |  | pull                push |  | pull
-                 v  |                          v  |
-            Worker_Component               Worker_Component
-                  |                             |
-starpu_pop_task   |                             |
-                  v                             v
-</pre>
-
-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.
-
-\subsection ExistingModularizedSchedulers Existing Modularized Schedulers
-
-StarPU is currently shipped with the following pre-defined Modularized
-Schedulers :
-
-- Eager-based Schedulers (with/without prefetching) : \n
-Naive scheduler, which tries to map a task on the first available resource
-it finds.
-
-- Prio-based Schedulers (with/without prefetching) : \n
-Similar to Eager-Based Schedulers. Can handle tasks which have a defined
-priority and schedule them accordingly.
-
-- Random-based Schedulers (with/without prefetching) : \n
-Selects randomly a resource to be mapped on for each task.
-
-- HEFT Scheduler : \n
-Heterogeneous Earliest Finish Time Scheduler.
-This scheduler needs that every task submitted to StarPU have a
-defined performance model (\ref PerformanceModelCalibration)
-to work efficiently, but can handle tasks without a performance
-model.
-
-To use one of these schedulers, one can set the environment variable \ref STARPU_SCHED.
-All modularized schedulers are named following the RE <c>tree-*</c>
-
-\subsection ExampleTreeEagerPrefetchingStrategy An Example : The Tree-Eager-Prefetching Strategy
-
-<pre>
                                  |
              starpu_push_task    |
                                  |
@@ -258,8 +194,20 @@ All modularized schedulers are named following the RE <c>tree-*</c>
       Pull    |  |    Can_Pull            Pull    |  |    Can_Pull
               v  |                                v  |
         Worker_Component                     Worker_Component
+                  |                             |
+starpu_pop_task   |                             |
+                  v                             v
 </pre>
 
+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.
+
 \subsection Interface
 
 Each Scheduling Component must follow the following pre-defined Interface