On 04/09/2015 12:10 PM, Henrik Austad wrote:
[...]
@@ -43,7 +43,13 @@ CONTENTS
"deadline", to schedule tasks. A SCHED_DEADLINE task should receive
"runtime" microseconds of execution time every "period" microseconds, and
these "runtime" microseconds are available within "deadline" microseconds
- from the beginning of the period. In order to implement this behaviour,
+ from the beginning of the period.
+
+ We can the describe a task in a concise manner:
+
+ T_i = {period, WCET, deadline}
+
+ In order to implement this behaviour,
Notice that these "period" and "runtime" are different things respect to the
task period and WCET described in Section 3 (the relationship between them is
explained at the end of Section 3: "Finally, it is important to understand the
relationship...").
Ok. I understood runtime as the dynamic value being managed by the
scheduler and should never exceed WCET (or being set to WCET upon release
and task preemption when runtime==0).
Uh... That's yet another thing (called "remaining runtime" in the document).
This is the situation:
1) A task is characterised by 3 parameters: WCET, D, and P. These only depend on the
application's code (how much time the application takes to do its work, how often
it activate, and how fast it should finish in order to respect its temporal
constraints).
Section 3 tries to introduce and describe these parameters (which come from real-time
literature).
2) The SCHED_DEADLINE scheduler accepts 3 scheduling parameters (as arguments of the
sched_setattr() system call): runtime, deadline and period. These are used by the
scheduler to assign a dynamic priority to the tasks. Described in Section 2.
3) Internally, the scheduler maintains some dynamic values (remaining budget and
scheduling deadline). The "remaining budget" starts from the "budget" value and
decreases when a task executes. When it arrives to 0 the task is throttled, etc...
The problem is that the scheduling parameters (runtime deadline and period, item 2
and Section 3) and the task's parameters (WCET D and P, item 1 and Section 2) are
conceptually two different things... And of course the task's temporal constraints
are respected only if the scheduling parameters are set in an appropriate way.
Luca
--
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
