Messages in this thread | | | Date | Mon, 02 Feb 2015 14:57:08 +0100 | From | Luca Abeni <> | Subject | Re: Another SCHED_DEADLINE bug (with bisection and possible fix) |
| |
Hi Peter,
On 01/31/2015 10:56 AM, Peter Zijlstra wrote: > On Fri, Jan 30, 2015 at 10:35:02AM +0000, Juri Lelli wrote: >> So, we do the safe thing only in case of throttling. > > No, even for the !throttle aka running tasks. We only use > dl_{runtime,deadline,period} for replenishment, until that time we > observe the old runtime/deadline set by the previous replenishment. > >> I guess is more than >> ok for now, while we hopefully find some spare cycle to implement a >> complete solution :/. > > Yeah, I bet the fun part is computing the 0-lag across the entire root > domain, per-cpu 0-lag isn't correct afaict. Uhm... This is an interesting problem.
I _suspect_ the 0-lag time does not depend on the number of CPUs. In other words: I _suspect_ that when you kill a SCHED_DEADLINE task its bandwidth should released at a time t0 = scheduling_deadline - current_budget / maximum_budget * period and this time is not affected by the fact that the task is scheduled by global EDF or by EDF on a single core. But I have no proof about this (and I changed my mind on this multiple times :).
On a side note: as far as I can see, releasing the bandwidth at the end of the current reservation period (that is, when the time is equal to the current scheduling deadline) should be safe. Basically, by doing this we assume that the task already consumed all of its budget for the current reservation period.
Luca
| |