periods and deadlines in SCHED_DEADLINE

[Raistlin]

Hi all,

So, talking to Peter and Thomas at the OSPERT workshop in Brussels [1],
the so called "sporaidic task model" came out many many times! Such
model comprises three parameters: wcet (or better budget or better
runtime :-D), deadline and period, where obviously deadline and period
could be different. However, SCHED_DEADLINE, since now, is using just
deadline, assuming that period is always equal to it.

Now, Peter said something about starting using period as well, but we
didn't have the time to discuss about that. Ironically, I got just a
couple of days before _the_same_ feature request by Harald from Ericsson
(in Cc), asking the very same thing.
So, this mail is to try to find a consensus (or just to gather your
opinions) on how to include this feature in the scheduler.

Since I'm about to release a new version, I would like, if possible, to
take these requests into account...

Here's the issue:
 - using periods for calculating the tasks' bandwidth and then using   
   deadlines for scheduling the tasks is going to work, but the
   admission control test that you would need for ensuring anybody
   will make its deadline is waaay more complex than Sum_i(BW_i)<1, even
   for uniprocessors/partitionig. That one instead would gives you just
   a very basic guarantee that the design in not completely broken
   (formally, I think I should say it is only a necessary
   condition :-)).

Therefore, here it is my proposal:
 - if the programmer specify both period and deadline, I act as above,
   running the _only_necessary_ test in the kernel, assuming that
   userspace performed some other kind of (correct!) admission test by
   its own, or that it is cool with missing some deadlines... What do
   you think?
 - do you think it could be useful to have a different syscall to deal
   with the period parameter (if it's different from deadline), e.g.,
   something useful to make the task periodic as you have (if I remember
   well) in Xenomai or RTAI?
   If you think it's worth doing that, do you think the
   task_wait_interval() syscall that we already added could/should do
   the job?

Basically, from the scheduling point of view, what it could happen is
that I'm still _NOT_ going to allow a task with runtime Q_i, deadline
D_i and period P_i to use more bandwidth than Q_i/P_i, I'm still using D
for scheduling but the passing of the simple in-kernel admission test
Sum_i(Q_i/P_i)<1 won't guarantee that the task will always finish its
jobs before D.

Please, if you find this interesting provide me with your comments,
otherwise, excuse me for bothering. :-)

Thanks and regards,
Dario

[1] http://www.artist-embedded.org/artist/Overview,1909.html

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@xxxxxxxxx /
dario.faggioli@xxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part