Hi Henrik, On 02/09/14 22:10, Henrik Austad wrote: > On Thu, Aug 28, 2014 at 11:00:26AM +0100, Juri Lelli wrote: >> From: Luca Abeni <luca.abeni@xxxxxxxx> >> >> Several small changes regarding SCHED_DEADLINE documentation that fix >> terminology and improve clarity and readability: >> >> - "current runtime" becomes "remaining runtime" >> >> - readablity of an equation is improved by introducing more spacing >> >> - clarify when admission control will certainly fail >> >> - new URL for CBS technical report >> >> - substitue "smallest" with "closest" > > I'm tempted to say "earliest" (being part of the algorithm's name and all > ;) > >> >> Signed-off-by: Luca Abeni <luca.abeni@xxxxxxxx> >> Signed-off-by: Juri Lelli <juri.lelli@xxxxxxx> >> Cc: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> >> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx> >> Cc: Ingo Molnar <mingo@xxxxxxxxxx> >> Cc: Henrik Austad <henrik@xxxxxxxxx> >> Cc: Dario Faggioli <raistlin@xxxxxxxx> >> Cc: Juri Lelli <juri.lelli@xxxxxxxxx> >> Cc: linux-doc@xxxxxxxxxxxxxxx >> Cc: linux-kernel@xxxxxxxxxxxxxxx >> --- >> Documentation/scheduler/sched-deadline.txt | 32 ++++++++++++++++-------------- >> 1 file changed, 17 insertions(+), 15 deletions(-) >> >> diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt >> index 18adc92..dce6d63 100644 >> --- a/Documentation/scheduler/sched-deadline.txt >> +++ b/Documentation/scheduler/sched-deadline.txt >> @@ -45,14 +45,14 @@ CONTENTS >> every time the task wakes up, the scheduler computes a "scheduling deadline" >> consistent with the guarantee (using the CBS[2,3] algorithm). Tasks are then >> scheduled using EDF[1] on these scheduling deadlines (the task with the >> - smallest scheduling deadline is selected for execution). Notice that this >> + closest scheduling deadline is selected for execution). Notice that this >> guaranteed is respected if a proper "admission control" strategy (see Section >> "4. Bandwidth management") is used. >> >> Summing up, the CBS[2,3] algorithms assigns scheduling deadlines to tasks so >> that each task runs for at most its runtime every period, avoiding any >> interference between different tasks (bandwidth isolation), while the EDF[1] >> - algorithm selects the task with the smallest scheduling deadline as the one >> + algorithm selects the task with the closest scheduling deadline as the one >> to be executed first. Thanks to this feature, also tasks that do not > > s/first/next/ > > Also, next sentence does not make much sense, I would drop the also; > > "Thanks to this feature, tasks that do not strictly comply with the ..." > >> strictly comply with the "traditional" real-time task model (see Section 3) >> can effectively use the new policy. >> @@ -64,45 +64,45 @@ CONTENTS >> "deadline", and "period" parameters; >> >> - The state of the task is described by a "scheduling deadline", and >> - a "current runtime". These two parameters are initially set to 0; >> + a "remaining runtime". These two parameters are initially set to 0; >> >> - When a SCHED_DEADLINE task wakes up (becomes ready for execution), >> the scheduler checks if >> >> - current runtime runtime >> - ---------------------------------- > ---------------- >> - scheduling deadline - current time period >> + remaining runtime runtime >> + ---------------------------------- > --------- >> + scheduling deadline - current time period >> >> then, if the scheduling deadline is smaller than the current time, or >> this condition is verified, the scheduling deadline and the >> - current budget are re-initialised as >> + remaining runtime are re-initialised as >> >> scheduling deadline = current time + deadline >> - current runtime = runtime >> + remaining runtime = runtime >> >> - otherwise, the scheduling deadline and the current runtime are >> + otherwise, the scheduling deadline and the remaining runtime are >> left unchanged; >> >> - When a SCHED_DEADLINE task executes for an amount of time t, its >> - current runtime is decreased as >> + remaining runtime is decreased as >> >> - current runtime = current runtime - t >> + remaining runtime = remaining runtime - t >> >> (technically, the runtime is decreased at every tick, or when the >> task is descheduled / preempted); >> >> - - When the current runtime becomes less or equal than 0, the task is >> + - When the remaining runtime becomes less or equal than 0, the task is >> said to be "throttled" (also known as "depleted" in real-time literature) >> and cannot be scheduled until its scheduling deadline. The "replenishment >> time" for this task (see next item) is set to be equal to the current >> value of the scheduling deadline; >> >> - When the current time is equal to the replenishment time of a >> - throttled task, the scheduling deadline and the current runtime are >> + throttled task, the scheduling deadline and the remaining runtime are >> updated as >> >> scheduling deadline = scheduling deadline + period >> - current runtime = current runtime + runtime >> + remaining runtime = remaining runtime + runtime >> >> >> 3. Scheduling Real-Time Tasks >> @@ -147,6 +147,8 @@ CONTENTS >> and the absolute deadlines (d_j) coincide, so a proper admission control >> allows to respect the jobs' absolute deadlines for this task (this is what is >> called "hard schedulability property" and is an extension of Lemma 1 of [2]). >> + Notice that if runtime > deadline the admission control will surely reject >> + this task, as it is not possible to respect its temporal constraints. >> >> References: >> 1 - C. L. Liu and J. W. Layland. Scheduling algorithms for multiprogram- >> @@ -156,7 +158,7 @@ CONTENTS >> Real-Time Systems. Proceedings of the 19th IEEE Real-time Systems >> 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://xoomer.virgilio.it/lucabe72/pubs/tr-98-01.ps >> + Technical Report. http://disi.unitn.it/~abeni/tr-98-01.pdf >> >> 4. Bandwidth management >> ======================= >> -- >> 2.0.4 > > Apart from the minor nitpick, it looks good! > Great! Nitpicks fixed. Thanks, - Juri -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
