The periodicity of scheduling
Sebastian Huber
sebastian.huber at embedded-brains.de
Mon Aug 8 14:12:36 UTC 2016
Hello Kuan-Hsun,
thanks for your analysis. I think we should provide your described
behaviour also in RTEMS since it is backed up by research results and it
is used in a reference implementation. We have two options.
1. We keep the existing RTEMS behaviour as is and enable the new variant
via some explicit function calls.
2. We change the existing RTEMS behaviour and possibly break
applications that depend on the old behaviour.
It would be nice to provide the non-portable POSIX-like API for
SCHED_DEADLINE of Linux with an implementation that matches the Linux
behaviour as good as possible.
On 08/08/16 15:20, Kuan Hsun Chen wrote:
>
> Hello Sebastian,
>
> Sorry, I spent some time to make sure the behaviour in Litmus RT. (I
> assume the Linux EDF scheduler you mentioned it provides by Litmus RT)
>
> For EDF case, you can find the implementation in curr_job_completion()
> in sched_gsn_edf.c, and job_completion() in sched_pfp.c for RMS case.
> By tracing back to the common function prepare_for_next_period() in
> jobs.c, we can notice that they also prepare a counter, i.e., job_no
> variable, to record how many jobs should be ideally released (without
> overrun).
>
> With sys_wait_for_job_release() in litmus.c, the task is only going to
> sleep only when its # of released job is larger than job_no by
> triggering complete_job() (like the case in RTEMS in
> rtems_rate_monotonic_period() deciding if the period is going to block).
> That means, the postponed jobs should be released continuously until
> there is no more postponed jobs, which also reaches my conclusion.
>
> Best,
> Kuan-Hsun
>
>
> 2016-08-01 15:58 GMT+02:00 Sebastian Huber
> <sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>>:
>
> Hello Kuan-Hsun,
>
> it would be interesting to know the behaviour of the Linux EDF
> scheduler in this case.
>
> On 01/08/16 15:49, Kuan Hsun Chen wrote:
>
> Hello All,
>
> I have used rate_monotonic function series to do some
> cycle-accuracy emulation quite a long time. I believe that
> some missing features of scheduling are essentially required.
> As I'm not aware of any discussion about this before, please
> correct me if I misunderstand.
>
> If I understand correctly, the current implementation of
> rtems_rate_monotonic_period() is explicitly assumed the
> implicit deadline or constraint deadline model that the task
> deadline is always less than or equal to the period deadline.
> If rtems_rate_monotonic_period() is called, it is the moment
> that either the task is finished on time or earlier than its
> period (or inactivate as the first call). If a task misses its
> period, the watchdog will mark the period as
> RATE_MONOTONIC_EXPIRED and update the deadline of watchdog.
>
> However, the behavior is not correct currently. From my point
> of view, the periodic task should always release its workload
> on time, even it misses its deadline. If there are already two
> expired periods, the task should have two more remaining
> instances workload to execute.
> Especially if the task has arbitrary deadline or even the task
> is a soft real time task, this feature should behave correctly.
> (Soft Real Time task: If a task misses its deadline, it is
> still valuable to gather its result no matter when. If the
> utilization of uniprocessor is not 100%, the tardiness is
> proved to be bounded.)
>
> Here I aim at a case that the task misses its deadline with
> the current implementation.
> If a task period is time out (marked as
> RATE_MONOTONIC_EXPIRED), by referring to
> _Rate_monotonic_Block_while_expired(), the next call of
> rtems_rate_monotonic_period() will only release *one*
> following instance and manipulate the task period with *the
> calling moment + the next length of period*. However, this way
> of scheduling is in fact changing the behaviour of a periodic
> task:
>
> 1. There may be more than one instances which are postponed
> due to
> the preemption of higher priority tasks. Trivially release
> only
> one instance is not correct in the sense of scheduling.
> 2. The period of expired task is shifted and unpredictable. This
> should be calculated correctly and rapidly by taking the time
> point of first period released. The deadline of watchdog
> in this
> case should be assigned with an absolute tick.
>
> I have enhanced this feature in the system by adding three
> additional counters in Rate_monotonic_Control structure and
> one more function to do the correct assignment of deadline and
> job release. I also prepare a heuristic example to demonstrate
> the results. I'm going to fix the case for arbitrary deadline
> later on.
>
> Please let me know if this feature is sound and essential. I
> can patch it.
>
> Best Regards,
> Kuan-Hsun
>
> --
> M.Sc. Kuan-Hsun Chen
>
> TU Dortmund
> Department of Computer Science 12
> Design Automation of Embedded Systems
> Otto-Hahn-Strasse 16, Room 102
>
> 44227 Dortmund
> Germany
>
> Phone: _+49 231 755 6124 <tel:%2B49%20231%20755%206124>_
> Mail: kuan-hsun.chen at tu-dortmund.de
> <mailto:kuan-hsun.chen at tu-dortmund.de>
> <mailto:kuan-hsun.chen at tu-dortmund.de
> <mailto:kuan-hsun.chen at tu-dortmund.de>>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org <mailto:users at rtems.org>
> http://lists.rtems.org/mailman/listinfo/users
> <http://lists.rtems.org/mailman/listinfo/users>
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16 <tel:%2B49%2089%20189%2047%2041-16>
> Fax : +49 89 189 47 41-09 <tel:%2B49%2089%20189%2047%2041-09>
> E-Mail : sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
>
>
> --
> M.Sc. Kuan-Hsun Chen
>
> TU Dortmund
> Department of Computer Science 12
> Design Automation of Embedded Systems
> Otto-Hahn-Strasse 16, Room 102
>
> 44227 Dortmund
> Germany
>
> Phone: _+49 231 755 6124 <tel:%2B49%20231%20755%206124>_
> Mail: kuan-hsun.chen at tu-dortmund.de <mailto:kuan-hsun.chen at tu-dortmund.de>
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the users
mailing list