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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
