From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752887AbcIJMvB (ORCPT ); Sat, 10 Sep 2016 08:51:01 -0400 Received: from terminus.zytor.com ([198.137.202.10]:44594 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751243AbcIJMvA (ORCPT ); Sat, 10 Sep 2016 08:51:00 -0400 Date: Sat, 10 Sep 2016 05:41:22 -0700 From: tip-bot for Tommaso Cucinotta Message-ID: Cc: tommaso.cucinotta@sssup.it, juri.lelli@arm.com, mingo@kernel.org, juri.lelli@gmail.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, hpa@zytor.com, torvalds@linux-foundation.org, bristot@redhat.com, luca.abeni@unitn.it, peterz@infradead.org Reply-To: peterz@infradead.org, bristot@redhat.com, luca.abeni@unitn.it, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, hpa@zytor.com, juri.lelli@arm.com, tglx@linutronix.de, juri.lelli@gmail.com, mingo@kernel.org, tommaso.cucinotta@sssup.it In-Reply-To: <1473443117-11794-2-git-send-email-tommaso.cucinotta@sssup.it> References: <1473443117-11794-2-git-send-email-tommaso.cucinotta@sssup.it> To: linux-tip-commits@vger.kernel.org Subject: [tip:sched/core] sched/deadline: Document behavior of sched_yield() Git-Commit-ID: b95202a3b6bb8715a716dbdb15cdb82bf622260b X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: b95202a3b6bb8715a716dbdb15cdb82bf622260b Gitweb: http://git.kernel.org/tip/b95202a3b6bb8715a716dbdb15cdb82bf622260b Author: Tommaso Cucinotta AuthorDate: Fri, 9 Sep 2016 19:45:17 +0200 Committer: Ingo Molnar CommitDate: Sat, 10 Sep 2016 11:17:41 +0200 sched/deadline: Document behavior of sched_yield() This is a documentation only patch, explaining the behavior of sched_yield() when a SCHED_DEADLINE task calls it (give up remaining runtime and be throttled until next period begins). Signed-off-by: Tommaso Cucinotta Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juri Lelli Reviewed-by: Luca Abeni Reviewed-by: Daniel Bristot de Oliveira Cc: Juri Lelli Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-dl@retis.sssup.it Link: http://lkml.kernel.org/r/1473443117-11794-2-git-send-email-tommaso.cucinotta@sssup.it Signed-off-by: Ingo Molnar --- Documentation/scheduler/sched-deadline.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt index 53a2fe1..8e37b0b 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,23 @@ 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 immediately throttled, until the next + period, when its runtime will be replenished (a special flag + dl_yielded is set and used to handle correctly throttling and runtime + replenishment after a call to sched_yield()). + + This behavior of sched_yield() 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 =====================