On 15/02/17 13:31, Luca Abeni wrote: > Hi Juri, > > On Wed, 15 Feb 2017 10:29:19 +0000 > Juri Lelli <juri.le...@arm.com> wrote: > [...] > > > Ok, thanks; I think I can now see why this can result in a task > > > consuming more than the reserved utilisation. I still need some > > > time to convince me that "runtime / (deadline - t) > dl_runtime / > > > dl_deadline" is the correct check to use (in this case, shouldn't > > > we also change the admission test to use densities instead of > > > utilisations?) > > > > Right, this is what I was wondering as well, as dl_overflow() > > currently looks at the period. And I also have some recollection of > > this discussion happening already in the past, unfortunately it was > > not on the list. > > > > That discussion started with the following patch > [...] > > that we then dediced not to propose since (note that these are just my > > memories of the dicussion, so everything it's up for further > > discussion, also in light of the problem highlighted by Daniel) > > > > - SCHED_DEADLINE, as the documentation says, does AC using > > utilization > > - it is however true that a sufficient (but not necessary) test on > > UP for D_i != P_i cases is the one of my patch above > > - we have agreed in the past that the kernel should only check that > > we don't cause "overload" in the system (which is still the case if we > > consider utilizations), not "hard schedulability" > I remember a similar discussion; I think the decision about what to do > depends on what are the requirements: hard deadline guarantees (but in > this case global EDF is just a bad choice) or tardines no overload > guarantees? > > My understanding was that the kernel guarantees that deadline tasks > will not starve non-deadline tasks, and that there is an upper bound > for the tardiness experienced by deadline tasks. If this understanding > is correct, then the current admission test is ok. But if I > misunderstood the purpose of the kernel admission test, then maybe your > patch is ok. > > Then, it is important to keep the admission test consistent with the > checks performed in dl_entity_overflow() (but whatever we decide to do, > dl_entity_overflow() should be fixed). >
I'm sorry, but I'm a bit lost. :( Why do you say 'whatever we decide to do'? In my understanding: - if we decide AC shouldn't change (as we care about not-starving others and having bounded tardiness), then I'd say dl_entity_overflow shouldn't change as well, since it's using dl_runtime/dl_period as 'static bandwidth' (as AC does) - if we instead move to use densities when doing AC (dl_runtime/dl_ deadline), I think we should also change the check in dl_entity_ overflow, as Steve is proposing - in both cases Daniel's fixes look sensible to have Where am I wrong? :) Actually, another thing that we noticed, talking on IRC with Peter, is that we seem to be replenishing differently on different occasions: - on wakeup (if overflowing) we do dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline; dl_se->runtime = pi_se->dl_runtime; - when the replenishment timer fires (un-thottle and with runtime < 0) dl_se->deadline += pi_se->dl_period; dl_se->runtime += pi_se->dl_runtime; Isn't this problematic as well? Thanks, - Juri
