On 13/02/2017 20:05, Daniel Bristot de Oliveira wrote:
To avoid this problem, in the activation of a constrained deadline
task after the deadline but before the next period, throttle the
task and set the replenishing timer to the begin of the next period,
unless it is boosted.
my only comment is that, by throttling on (dl < wakeuptime < period), we force the
app to sync its activation time with the kernel, and the cbs doesn't self-sync anymore
with the app own periodicity, which is what normally happens with dl=period. With
dl=period, we loose the cbs self-sync and we force the app to sync with the kernel
periodic timer only if we use explicitly yield(), but now this becomes also implicit
just if we set dl<period.
attr.sched_policy = SCHED_DEADLINE;
attr.sched_runtime = 2 * 1000 * 1000; /* 2 ms */
attr.sched_deadline = 2 * 1000 * 1000; /* 2 ms */
attr.sched_period = 2 * 1000 * 1000 * 1000; /* 2 s */
...
On my box, this reproducer uses almost 50% of the CPU time, which is
obviously wrong for a task with 2/2000 reservation.
just a note here: in this example of runtime=deadline=2ms, shall we rely
on a utilization-based test, then we should assume the task is taking 100%.
More precise tests for EDF with deadline<period would properly count the
1998ms/2000ms free space, instead.
my2c,
T.
--
Tommaso Cucinotta, Computer Engineering PhD
Associate Professor at the Real-Time Systems Laboratory (ReTiS)
Scuola Superiore Sant'Anna, Pisa, Italy
http://retis.sssup.it/people/tommaso
