lkml.org 
[lkml]   [2017]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH V2 1/2] sched/deadline: Replenishment timer should fire in the next period
    Date
    Currently, the replenishment timer is set to fire at the deadline
    of a task. Although that works for implicit deadline tasks because the
    deadline is equals to the begin of the next period, that is not correct
    for constrained deadline tasks (deadline < period).

    For instance:

    f.c:
    --------------- %< ---------------
    int main (void)
    {
    for(;;);
    }
    --------------- >% ---------------

    # gcc -o f f.c

    # trace-cmd record -e sched:sched_switch \
    -e syscalls:sys_exit_sched_setattr \
    chrt -d --sched-runtime 490000000 \
    --sched-deadline 500000000 \
    --sched-period 1000000000 0 ./f

    # trace-cmd report | grep "{pid of ./f}"

    After setting parameters, the task is replenished and continue running
    until being throttled.
    f-11295 [003] 13322.113776: sys_exit_sched_setattr: 0x0

    The task is throttled after running 492318 ms, as expected.
    f-11295 [003] 13322.606094: sched_switch: f:11295 [-1] R ==> \
    watchdog/3:32 [0]

    But then, the task is replenished 500719 ms after the first
    replenishment:
    <idle>-0 [003] 13322.614495: sched_switch: swapper/3:0 [120] R \
    ==> f:11295 [-1]

    Running for 490277 ms:
    f-11295 [003] 13323.104772: sched_switch: f:11295 [-1] R ==> \
    swapper/3:0 [120]

    Hence, in the first period, the task runs 2 * runtime, and that is a bug.

    During the first replenishment, the next deadline is set one period away.
    So the runtime / period starts to be respected. However, as the second
    replenishment took place in the wrong instant, the next replenishment
    will also be held in a wrong instant of time. Rather than occurring in
    the nth period away from the first activation, it is taking place
    in the (nth period - relative deadline).

    Signed-off-by: Daniel Bristot de Oliveira <bristot@redhat.com>
    Reviewed-by: Luca Abeni <luca.abeni@santannapisa.it>
    Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Reviewed-by: Juri Lelli <juri.lelli@arm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Juri Lelli <juri.lelli@arm.com>
    Cc: Tommaso Cucinotta <tommaso.cucinotta@sssup.it>
    Cc: Luca Abeni <luca.abeni@santannapisa.it>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Romulo Silva de Oliveira <romulo.deoliveira@ufsc.br>
    Cc: linux-kernel@vger.kernel.org
    ---
    kernel/sched/deadline.c | 9 +++++++--
    1 file changed, 7 insertions(+), 2 deletions(-)

    diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
    index 70ef2b1..3c94d85 100644
    --- a/kernel/sched/deadline.c
    +++ b/kernel/sched/deadline.c
    @@ -505,10 +505,15 @@ static void update_dl_entity(struct sched_dl_entity *dl_se,
    }
    }

    +static inline u64 dl_next_period(struct sched_dl_entity *dl_se)
    +{
    + return dl_se->deadline - dl_se->dl_deadline + dl_se->dl_period;
    +}
    +
    /*
    * If the entity depleted all its runtime, and if we want it to sleep
    * while waiting for some new execution time to become available, we
    - * set the bandwidth enforcement timer to the replenishment instant
    + * set the bandwidth replenishment timer to the replenishment instant
    * and try to activate it.
    *
    * Notice that it is important for the caller to know if the timer
    @@ -530,7 +535,7 @@ static int start_dl_timer(struct task_struct *p)
    * that it is actually coming from rq->clock and not from
    * hrtimer's time base reading.
    */
    - act = ns_to_ktime(dl_se->deadline);
    + act = ns_to_ktime(dl_next_period(dl_se));
    now = hrtimer_cb_get_time(timer);
    delta = ktime_to_ns(now) - rq_clock(rq);
    act = ktime_add_ns(act, delta);
    --
    2.9.3
    \
     
     \ /
      Last update: 2017-02-13 20:07    [W:3.370 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site