This is a documentation only patch, explaining the behavior of sched_yield() when a SCHED_DEADLINE task calls it (give up remaining runtime and suspend till next period).
Signed-off-by: Tommaso Cucinotta <[email protected]> Reviewed-by: Juri Lelli <[email protected]> --- Documentation/scheduler/sched-deadline.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt index 53a2fe1..cb43421 100644 --- a/Documentation/scheduler/sched-deadline.txt +++ b/Documentation/scheduler/sched-deadline.txt @@ -16,6 +16,7 @@ CONTENTS 4.1 System-wide settings 4.2 Task interface 4.3 Default behavior + 4.4 Behavior of sched_yield() 5. Tasks CPU affinity 5.1 SCHED_DEADLINE and cpusets HOWTO 6. Future plans @@ -426,6 +427,18 @@ CONTENTS Finally, notice that in order not to jeopardize the admission control a -deadline task cannot fork. +4.4 Behavior of sched_yield() +----------------------------- + + When a SCHED_DEADLINE task calls sched_yield(), it gives up its + remaining runtime and is suspended till the next reservation period, + when its runtime will be replenished. This allows the task to + wake-up exactly at the beginning of the next period. Also, this may + be useful in the future with bandwidth reclaiming mechanisms, where + sched_yield() will make the leftoever runtime available for + reclamation by other SCHED_DEADLINE tasks. + + 5. Tasks CPU affinity ===================== -- 2.7.4
