On Wed, May 24, 2017 at 12:01:51PM +0200, Luca Abeni wrote: > > > So I'm terribly confused... > > > > > > By using the active bandwidth to select frequency we effectively > > > reduce idle time (to 0 if we had infinite granular frequency steps > > > and no margins). > > > > > > So !RECLAIM works as expected. They get the time they reserved, > > > since that was taken into account by active bandwidth.
> Well, I also admitted that I am almost completely ignorant about many > people's requirements... > > What I know is that there are some people using SCHED_DEADLINE to make > sure that a task can make progress (executing with a "high priority") > without consuming more than a specified fraction of CPU time... So, > they for example schedule a CPU-hungry task with runtime=10ms and > period=100ms to make sure that the task can execute every 100ms (giving > the impression of a "fluid progress") without stealing more than 10% of > CPU time to other tasks. > > In this case, if the CPU frequency change the goal is still to > "reserve" 10% of CPU time (not more, even if the CPU is slower) to the > task. So, no runtime rescaling (or reclaiming) is required in this case. > > > My proposal was that if a task is not interested in a fixed > runtime / fraction of CPU time but wants to adapt the runtime when the > CPU frequency scales, then it can select the RECLAIMING flag. I think these people are doing it wrong :-) Firstly, the runtime budget is a WCET. This very much means it is subject to CPU frequency; after all, when the CPU runs slower, that same amount of work takes longer. So being subject to cpufreq is the natural state and should not require a special marker. Secondly, if you want a steady progress of 10%, I don't see the problem with giving them more at slower frequency, they get the 'same' amount of 'work' done without bothering other people.
