From: Luca Abeni <luca.abeni@unitn.it>
To: Henrik Austad <henrik@austad.us>
Cc: Luca Abeni <lucabe72@gmail.com>,
peterz@infradead.org, juri.lelli@gmail.com, raistlin@linux.it,
mingo@kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [RFC 3/4] Documentation/scheduler/sched-deadline.txt: Some notes on EDF schedulability
Date: Thu, 09 Apr 2015 12:35:20 +0200 [thread overview]
Message-ID: <552655E8.4020606@unitn.it> (raw)
In-Reply-To: <20150409101058.GC10954@sisyphus.home.austad.us>
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
next prev parent reply other threads:[~2015-04-09 10:35 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 ` [RFC 3/4] Documentation/scheduler/sched-deadline.txt: Some notes on EDF schedulability Luca Abeni
2015-04-09 9:06 ` Henrik Austad
2015-04-09 9:34 ` Luca Abeni
2015-04-09 10:10 ` Henrik Austad
2015-04-09 10:35 ` Luca Abeni [this message]
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=552655E8.4020606@unitn.it \
--to=luca.abeni@unitn.it \
--cc=henrik@austad.us \
--cc=juri.lelli@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucabe72@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).