lkml.org 
[lkml]   [2015]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 3/4] Documentation/scheduler/sched-deadline.txt: Some notes on EDF schedulability
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


\
 
 \ /
  Last update: 2015-04-09 13:01    [W:0.089 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site