Move scheduling implementation-related paragraph to scheduling implementation chapter

doc/doxygen/chapters/320_scheduling.doxy

@@ -2,7 +2,7 @@
  *
  * Copyright (C) 2010-2019                                CNRS
  * Copyright (C) 2011,2012,2016                           Inria
- * Copyright (C) 2009-2011,2014-2018                      Université de Bordeaux
+ * Copyright (C) 2009-2011,2014-2019                      Université de Bordeaux
  *
  * StarPU is free software; you can redistribute it and/or modify
  * it under the terms of the GNU Lesser General Public License as published by
@@ -217,49 +217,4 @@ contexts, otherwise the workers' corresponding scheduling structures may not be
 the execution of the application may deadlock. Moreover, the hypervisor should not be used when
 statically scheduling tasks.
 
-\section GraphScheduling Graph-based Scheduling
-
-For performance reasons, most of the schedulers shipped with StarPU use simple
-list-scheduling heuristics, assuming that the application has already set
-priorities.  This is why they do their scheduling between when tasks become
-available for execution and when a worker becomes idle, without looking at the
-task graph.
-
-Other heuristics can however look at the task graph. Recording the task graph
-is expensive, so it is not available by default, the scheduling heuristic has
-to set \c _starpu_graph_record to \c 1 from the initialization function, to make it
-available. Then the <c>_starpu_graph*</c> functions can be used.
-
-<c>src/sched_policies/graph_test_policy.c</c> is an example of simple greedy
-policy which automatically computes priorities by bottom-up rank.
-
-The idea is that while the application submits tasks, they are only pushed
-to a bag of tasks. When the application is finished with submitting tasks,
-it calls starpu_do_schedule() (or starpu_task_wait_for_all(), which calls
-starpu_do_schedule()), and the starpu_sched_policy::do_schedule method of the
-scheduler is called. This method calls _starpu_graph_compute_depths to compute
-the bottom-up ranks, and then uses these ranks to set priorities over tasks.
-
-It then has two priority queues, one for CPUs, and one for GPUs, and uses a dumb
-heuristic based on the duration of the task over CPUs and GPUs to decide between
-the two queues. CPU workers can then pop from the CPU priority queue, and GPU
-workers from the GPU priority queue.
-
-\section DebuggingScheduling Debugging Scheduling
-
-All the \ref OnlinePerformanceTools and \ref OfflinePerformanceTools can
-be used to get information about how well the execution proceeded, and thus the
-overall quality of the execution.
-
-Precise debugging can also be performed by using the
-\ref STARPU_TASK_BREAK_ON_PUSH, \ref STARPU_TASK_BREAK_ON_SCHED,
-\ref STARPU_TASK_BREAK_ON_POP, and \ref STARPU_TASK_BREAK_ON_EXEC environment variables.
-By setting the job_id of a task
-in these environment variables, StarPU will raise <c>SIGTRAP</c> when the task is being
-scheduled, pushed, or popped by the scheduler. This means that when one notices
-that a task is being scheduled in a seemingly odd way, one can just reexecute
-the application in a debugger, with some of those variables set, and the
-execution will stop exactly at the scheduling points of this task, thus allowing
-to inspect the scheduler state, etc.
-
 */

doc/doxygen/chapters/350_scheduling_policy_definition.doxy

@@ -2,7 +2,7 @@
  *
  * Copyright (C) 2013                                     Inria
  * Copyright (C) 2014,2016-2018                           CNRS
- * Copyright (C) 2014,2017                                Université de Bordeaux
+ * Copyright (C) 2014,2017,2019                           Université de Bordeaux
  * Copyright (C) 2013                                     Simon Archipoff
  *
  * StarPU is free software; you can redistribute it and/or modify
@@ -411,4 +411,49 @@ The Tree-Eager-Prefetching Scheduler shown in Section
                 Worker_Component                     Worker_Component
 </pre>
 
+\section GraphScheduling Graph-based Scheduling
+
+For performance reasons, most of the schedulers shipped with StarPU use simple
+list-scheduling heuristics, assuming that the application has already set
+priorities.  This is why they do their scheduling between when tasks become
+available for execution and when a worker becomes idle, without looking at the
+task graph.
+
+Other heuristics can however look at the task graph. Recording the task graph
+is expensive, so it is not available by default, the scheduling heuristic has
+to set \c _starpu_graph_record to \c 1 from the initialization function, to make it
+available. Then the <c>_starpu_graph*</c> functions can be used.
+
+<c>src/sched_policies/graph_test_policy.c</c> is an example of simple greedy
+policy which automatically computes priorities by bottom-up rank.
+
+The idea is that while the application submits tasks, they are only pushed
+to a bag of tasks. When the application is finished with submitting tasks,
+it calls starpu_do_schedule() (or starpu_task_wait_for_all(), which calls
+starpu_do_schedule()), and the starpu_sched_policy::do_schedule method of the
+scheduler is called. This method calls _starpu_graph_compute_depths to compute
+the bottom-up ranks, and then uses these ranks to set priorities over tasks.
+
+It then has two priority queues, one for CPUs, and one for GPUs, and uses a dumb
+heuristic based on the duration of the task over CPUs and GPUs to decide between
+the two queues. CPU workers can then pop from the CPU priority queue, and GPU
+workers from the GPU priority queue.
+
+\section DebuggingScheduling Debugging Scheduling
+
+All the \ref OnlinePerformanceTools and \ref OfflinePerformanceTools can
+be used to get information about how well the execution proceeded, and thus the
+overall quality of the execution.
+
+Precise debugging can also be performed by using the
+\ref STARPU_TASK_BREAK_ON_PUSH, \ref STARPU_TASK_BREAK_ON_SCHED,
+\ref STARPU_TASK_BREAK_ON_POP, and \ref STARPU_TASK_BREAK_ON_EXEC environment variables.
+By setting the job_id of a task
+in these environment variables, StarPU will raise <c>SIGTRAP</c> when the task is being
+scheduled, pushed, or popped by the scheduler. This means that when one notices
+that a task is being scheduled in a seemingly odd way, one can just reexecute
+the application in a debugger, with some of those variables set, and the
+execution will stop exactly at the scheduling points of this task, thus allowing
+to inspect the scheduler state, etc.
+
 */