More details on schedulers

doc/doxygen/chapters/08scheduling.doxy

@@ -10,6 +10,19 @@
 
 \section TaskSchedulingPolicy Task Scheduling Policy
 
+The basics of the scheduling policy are that
+
+<ul>
+<li>The scheduler gets to schedule tasks (<c>push</c> operation) when they become
+ready to be executed, i.e. they are not waiting for some tags, data dependencies
+or task dependencies.</li>
+<li>Workers pull tasks (<c>pop</c> operation) one by one from the scheduler.
+</ul>
+
+This means scheduling policies usually contain at least one queue of tasks to
+store them between the time when they become available, and the time when a
+worker gets to grab them.
+
 By default, StarPU uses the simple greedy scheduler <c>eager</c>. This is
 because it provides correct load balance even if the application codelets do not
 have performance models. If your application codelets have performance models
@@ -17,35 +30,38 @@ have performance models. If your application codelets have performance models
 to the environment variable \ref STARPU_SCHED. For instance <c>export
 STARPU_SCHED=dmda</c> . Use <c>help</c> to get the list of available schedulers.
 
-The <b>eager</b> scheduler uses a central task queue, from which workers draw tasks
-to work on. This however does not permit to prefetch data since the scheduling
+The <b>eager</b> scheduler uses a central task queue, from which all workers draw tasks
+to work on concurrently. This however does not permit to prefetch data since the scheduling
 decision is taken late. If a task has a non-0 priority, it is put at the front of the queue.
 
 The <b>prio</b> scheduler also uses a central task queue, but sorts tasks by
 priority (between -5 and 5).
 
-The <b>random</b> scheduler distributes tasks randomly according to assumed worker
+The <b>random</b> scheduler uses a queue per worker, and distributes tasks randomly according to assumed worker
 overall performance.
 
-The <b>ws</b> (work stealing) scheduler schedules tasks on the local worker by
+The <b>ws</b> (work stealing) scheduler uses a queue per worker, and schedules
+a task on the worker which released it by
 default. When a worker becomes idle, it steals a task from the most loaded
 worker.
 
 The <b>dm</b> (deque model) scheduler uses task execution performance models into account to
-perform an HEFT-similar scheduling strategy: it schedules tasks where their
-termination time will be minimal. The difference with HEFT is that tasks are
-scheduled in the order they become available.
+perform a HEFT-similar scheduling strategy: it schedules tasks where their
+termination time will be minimal. The difference with HEFT is that <b>dm</b>
+schedules tasks as soon as they become available, and thus in the order they
+become available, without taking priorities into account.
 
 The <b>dmda</b> (deque model data aware) scheduler is similar to dm, but it also takes
 into account data transfer time.
 
 The <b>dmdar</b> (deque model data aware ready) scheduler is similar to dmda,
-it also sorts tasks on per-worker queues by number of already-available data
+but it also sorts tasks on per-worker queues by number of already-available data
 buffers on the target device.
 
 The <b>dmdas</b> (deque model data aware sorted) scheduler is similar to dmdar,
 except that it sorts tasks by priority order, which allows to become even closer
-to HEFT.
+to HEFT by respecting priorities after having made the scheduling decision (but
+it still schedules tasks in the order they become available).
 
 The <b>heft</b> (heterogeneous earliest finish time) scheduler is a deprecated
 alias for <b>dmda</b>.