starpu-max/doc/chapters/sched_ctx.texi

@c -*-texinfo-*-

@c This file is part of the StarPU Handbook.
@c Copyright (C) 2009--2011  Universit@'e de Bordeaux 1
@c Copyright (C) 2010, 2011, 2012, 2013  Centre National de la Recherche Scientifique
@c Copyright (C) 2011--2013 Institut National de Recherche en Informatique et Automatique
@c See the file starpu.texi for copying conditions.

TODO: improve!

@menu
* General Idea::
* Create a Context::
* Modify a Context::
* Delete a Context::
* Empty Context::
* Contexts Sharing Workers::
@end menu

@node General Idea
@section General Idea
Scheduling contexts represent abstracts sets of workers that allow the programmers to control the distribution of computational resources (i.e. CPUs and
GPUs) to concurrent parallel kernels. The main goal is to minimize interferences between the execution of multiple parallel kernels, by partitioning the underlying pool of workers using contexts.

@node Create a Context
@section Create a Context
By default, the application submits tasks to an initial context, which disposes of all the computation ressources available to StarPU (all the workers). 
If the application programmer plans to launch several parallel kernels simultaneusly, by default these kernels will be executed within this initial context, using a single scheduler policy(@pxref{Task scheduling policy}).
Meanwhile, if the application programmer is aware of the demands of these kernels and of the specificity of the machine used to execute them, the workers can be divided between several contexts. 
These scheduling contexts will isolate the execution of each kernel and they will permit the use of a scheduling policy proper to each one of them.
In order to create the contexts, you have to know the indentifiers of the workers running within StarPU. 
By passing a set of workers together with the scheduling policy to the function @code{starpu_sched_ctx_create}, you will get an identifier of the context created which you will use to indicate the context you want to submit the tasks to.

@cartouche
@smallexample
/* @b{the list of ressources the context will manage} */
int workerids[3] = @{1, 3, 10@};

/* @b{indicate the scheduling policy to be used within the context, the list of 
   workers assigned to it, the number of workers, the name of the context} */
int id_ctx = starpu_sched_ctx_create("dmda", workerids, 3, "my_ctx");

/* @b{let StarPU know that the folowing tasks will be submitted to this context} */
starpu_sched_ctx_set_task_context(id);

/* @b{submit the task to StarPU} */
starpu_task_submit(task);

@end smallexample
@end cartouche

Note: Parallel greedy and parallel heft scheduling policies do not support the existence of several disjoint contexts on the machine. 
Combined workers are constructed depending on the entire topology of the machine, not only the one belonging to a context.


@node Modify a Context
@section Modify a Context
A scheduling context can be modified dynamically. The applications may change its requirements during the execution and the programmer can add additional workers to a context or remove if no longer needed.
In the following example we have two scheduling contexts @code{sched_ctx1} and @code{sched_ctx2}. After executing a part of the tasks some of the workers of @code{sched_ctx1} will be moved to context @code{sched_ctx2}.

@cartouche
@smallexample
/* @b{the list of ressources that context 1 will give away} */
int workerids[3] = @{1, 3, 10@};

/* @b{add the workers to context 1} */
starpu_sched_ctx_add_workers(workerids, 3, sched_ctx2);

/* @b{remove the workers from context 2} */
starpu_sched_ctx_remove_workers(workerids, 3, sched_ctx1);

@end smallexample
@end cartouche

@node Delete a Context 
@section Delete a Context
When a context is no longer needed it must be deleted. The application can indicate which context should keep the resources of a deleted one. 
All the tasks of the context should be executed before doing this. If the application need to avoid a barrier before moving the resources from the deleted context to the inheritor one, the application can just indicate
when the last task was submitted. Thus, when this last task was submitted the resources will be move, but the context should still be deleted at some point of the application.

@cartouche
@smallexample
/* @b{when the context 2 will be deleted context 1 will be keep its resources} */
starpu_sched_ctx_set_inheritor(sched_ctx2, sched_ctx1);

/* @b{submit tasks to context 2} */
for (i = 0; i < ntasks; i++)
    starpu_task_submit_to_ctx(task[i],sched_ctx2);

/* @b{indicate that context 2 finished submitting and that } */
/* @b{as soon as the last task of context 2 finished executing } */
/* @b{its workers can be mobed to the inheritor context} */
starpu_sched_ctx_finished_submit(sched_ctx1);

/* @b{wait for the tasks of both contexts to finish} */
starpu_task_wait_for_all();

/* @b{delete context 2} */
starpu_sched_ctx_delete(sched_ctx2);

/* @b{delete context 1} */
starpu_sched_ctx_delete(sched_ctx1);
@end smallexample
@end cartouche

@node Empty Context
@section Empty Context
A context may not have any resources at the begining or at a certain moment of the execution. Task can still be submitted to these contexts and they will execute them as soon as they will have resources. 
A list of tasks pending to be executed is kept and when workers are added to the contexts the tasks are submitted. However, if no resources are allocated the program will not terminate.
If these tasks have not much priority the programmer can forbid the application to submitted them by calling the function @code{starpu_sched_ctx_stop_task_submission}.

@node Contexts Sharing Workers
@section Contexts Sharing Workers
Contexts may share workers when a single context cannot execute efficiently enough alone on these workers or when the application decides to express a hierarchy of contexts. The workers apply 
an alogrithm of ``Round-Robin'' to chose the context on which they will ``pop'' next. By using the function @code{void starpu_sched_ctx_set_turn_to_other_ctx(int workerid, unsigned sched_ctx_id)}
the programmer can impose the @code{workerid} to ``pop'' in the context @code{sched_ctx_id} next.