On Sat, Feb 11, 2017 at 08:12:37AM +0100, luca abeni wrote: > Hi Daniel, > > On Fri, 10 Feb 2017 20:48:10 +0100 > Daniel Bristot de Oliveira <[email protected]> wrote: > > [...] > > 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)); > > Looks like there is a real bug in the code, and your fix looks correct > to me. I think it should be committed. >
I've interpreted this as: Reviewed-by: Luca Abeni <[email protected]> Holler if you disagree.
