mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Luca Abeni <lucabe72@gmail.com>
To: peterz@infradead.org
Cc: henrik@austad.us, juri.lelli@gmail.com, raistlin@linux.it,
	mingo@kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, Luca Abeni <luca.abeni@unitn.it>
Subject: [RFC 3/4] Documentation/scheduler/sched-deadline.txt: Some notes on EDF schedulability
Date: Wed,  8 Apr 2015 13:59:39 +0200	[thread overview]
Message-ID: <1428494380-1917-4-git-send-email-luca.abeni@unitn.it> (raw)
In-Reply-To: <1428494380-1917-1-git-send-email-luca.abeni@unitn.it>

Add a short discussion about sufficient and necessary schedulability tests,
and a simple example showing that if D_i != P_i then density based tests
are only sufficient.
Also add some references to scientific papers on schedulability tests for
EDF that are both necessary and sufficient, and on their computational
complexity.
---
 Documentation/scheduler/sched-deadline.txt |   40 ++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt
index 39341d9..ffaf95f 100644
--- a/Documentation/scheduler/sched-deadline.txt
+++ b/Documentation/scheduler/sched-deadline.txt
@@ -171,8 +171,34 @@ CONTENTS
  If D_i != P_i for some task, then it is possible to define the density of
  a task as WCET_i/min{D_i,P_i}, and EDF is able to respect all the deadlines
  of all the tasks running on a CPU if the sum sum_i WCET_i/min{D_i,P_i} of the
- densities of the tasks running on such a CPU is smaller or equal than 1
- (notice that this condition is only sufficient, and not necessary).
+ densities of the tasks running on such a CPU is smaller or equal than 1:
+	sum_i WCET_i / min{D_i, P_i} <= 1
+ It is important to notice that this condition is only sufficient, and not
+ necessary: there are task sets that are schedulable, but do not respect the
+ condition. For example, consider the task set {Task_1,Task_2} composed by
+ Task_1 with period P_1=100ms, relative deadline D_1=50ms and worst case
+ execution time WCET_1=50ms, and Task_2 with period P_2=100ms, relative
+ deadline D_2=100ms and worst case execution time WCET_2=10ms.
+ EDF is clearly able to schedule the two tasks without missing any deadline
+ (Task_1 is scheduled as soon as it is released, and finishes just in time
+ to respect its deadline; Task_2 is scheduled immediately after Task_1, hence
+ its response time cannot be larger than 50ms + 10ms = 60ms) even if
+	50 / min{50,100} + 10 / min{100, 100} = 50 / 50 + 10 / 100 = 1.1
+ Of course it is possible to test the exact schedulability of tasks with
+ D_i != P_i (checking a condition that is both sufficient and necessary),
+ but this cannot be done by comparing the total utilisation or density with
+ a constant. Instead, the so called "processor demand" approach can be used,
+ computing the total amount of CPU time h(t) needed by all the tasks to
+ respect all of their deadlines in a time interval of size t, and comparing
+ such a time with the interval size t. If for all values of t h(t) < t, then
+ EDF is able to schedule the tasks respecting all of their deadlines. Since
+ performing this check for all possible values of t is impossible, it has been
+ proven[4,5,6] that it is sufficient to perform the test for values of t
+ between 0 and a maximum value L. The cited papers contain all of the
+ mathematical details and explain how to compute h(t) and L.
+ In any case, this kind of analysis is too complex to be performed as an
+ admission test in the kernel (hence, as explained in Section 4 Linux uses
+ an admission test based on the tasks' utilisations).
 
  On multiprocessor systems with global EDF scheduling (non partitioned
  systems), a sufficient test for schedulability can not be based on the
@@ -206,6 +232,16 @@ CONTENTS
       Symposium, 1998. http://retis.sssup.it/~giorgio/paps/1998/rtss98-cbs.pdf
   3 - L. Abeni. Server Mechanisms for Multimedia Applications. ReTiS Lab
       Technical Report. http://disi.unitn.it/~abeni/tr-98-01.pdf
+  4 - J. Y. Leung and M.L. Merril. A Note on Preemptive Scheduling of
+      Periodic, Real-Time Tasks. Information Processing Letters, vol. 11,
+      no. 3, pp. 115-118, 1980.
+  5 - S. K. Baruah, A. K. Mok and L. E. Rosier. Preemptively Scheduling
+      Hard-Real-Time Sporadic Tasks on One Processor. Proceedings of the
+      11th IEEE Real-time Systems Symposium, 1990.
+  6 - S. K. Baruah, L. E. Rosier and R. R. Howell. Algorithms and Complexity
+      Concerning the Preemptive Scheduling of Periodic Real-Time tasks on
+      One Processor. Real-Time Systems Journal, vol. 4, no. 2, pp 301-324,
+      1990.
 
 4. Bandwidth management
 =======================
-- 
1.7.9.5


  parent reply	other threads:[~2015-04-08 12:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08 11:59 [RFC 0/4] SCHED_DEADLINE documentation update Luca Abeni
2015-04-08 11:59 ` [RFC 1/4] Documentation/scheduler/sched-deadline.txt: fix typos Luca Abeni
2015-04-08 11:59 ` [RFC 2/4] Documentation/scheduler/sched-deadline.txt: use consistent namings Luca Abeni
2015-04-08 11:59 ` Luca Abeni [this message]
2015-04-09  9:06   ` [RFC 3/4] Documentation/scheduler/sched-deadline.txt: Some notes on EDF schedulability Henrik Austad
2015-04-09  9:34     ` Luca Abeni
2015-04-09 10:10       ` Henrik Austad
2015-04-09 10:35         ` Luca Abeni
2015-04-08 11:59 ` [RFC 4/4] Documentation/scheduler/sched-deadline.txt: add some references Luca Abeni
2015-04-08 14:43   ` Peter Zijlstra
2015-04-09  8:24   ` Juri Lelli
2015-04-09  9:13     ` Luca Abeni
2015-04-09  9:39   ` Henrik Austad
2015-04-09  9:44     ` Peter Zijlstra
2015-04-09 10:08       ` Luca Abeni
2015-04-09 10:11         ` Peter Zijlstra
2015-04-09 10:13           ` Henrik Austad
2015-04-09 11:55             ` Ingo Molnar
2015-04-09 10:05     ` Luca Abeni
2015-04-09 10:17       ` Henrik Austad
2015-04-08 14:44 ` [RFC 0/4] SCHED_DEADLINE documentation update Peter Zijlstra
2015-04-09  9:13   ` Luca Abeni
2015-04-09  9:17     ` Peter Zijlstra
2015-04-09  9:19       ` Luca Abeni
2015-04-09  9:29         ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1428494380-1917-4-git-send-email-luca.abeni@unitn.it \
    --to=lucabe72@gmail.com \
    --cc=henrik@austad.us \
    --cc=juri.lelli@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.abeni@unitn.it \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=raistlin@linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®