Hi Luca, On Wednesday 06 Jun 2018 at 23:05:36 (+0200), luca abeni wrote: > Hi, > > On Wed, 6 Jun 2018 14:20:46 +0100 > Quentin Perret <quentin.per...@arm.com> wrote: > [...] > > > However, IMHO, these are corner cases and in the average case it is > > > better to rely on running_bw and reduce the CPU frequency > > > accordingly. > > > > My point was that accepting to go at a lower frequency than required > > by this_bw is fundamentally unsafe. If you're at a low frequency when > > a DL task starts, there are real situations where you won't be able > > to increase the frequency immediately, which can eventually lead to > > missing deadlines. Now, if this risk is known, has been discussed, > > and is accepted, that's fair enough. I'm just too late for the > > discussion :-) > > Well, our conclusion was that this issue can be addressed when > designing the scheduling parameters: > - If we do not consider frequency scaling, a task can respect its > deadlines if the SCHED_DEADLINE runtime is larger than the task's > execution time and the SCHED_DEADLINE period is smaller than the > task's period (and if some kind of "global" admission test is > respected) > - Considering frequency scaling (and 0-time frequency switches), the > SCHED_DEADLINE runtime must be larger than the task execution time at > the highest frequency > - If the frequency switch time is larger than 0, then the > SCHED_DEADLINE runtime must be larger than the task execution time > (at the highest frequency) plus the frequency switch time > > If this third condition is respected, I think that deadline misses can > be avoided even if running_bw is used (and the CPU takes a considerable > time to switch frequency). Of course, this requires an over-allocation > of runtime (and the global admission test has more probabilities to > fail)...
Ah, right, this third condition should definitely be a valid workaround to the issue I mentioned earlier. And the runtime parameter is already very much target-dependent I guess, so it should be fine to add another target-specific component (the frequency-switching time) to the runtime estimation. And, if you really need to have tight runtimes to fit all of your tasks, then you should just use a fixed frequency I guess ... At least the current implementation gives a choice to the user between being energy-efficient using sugov with over-allocated runtimes and having tighter runtimes with the performance/powersave/userspace governor, so that's all good :-) Thank you very much, Quentin
