On 15/03/17 16:40, Joel Fernandes wrote: > On Wed, Mar 15, 2017 at 9:24 AM, Juri Lelli <[email protected]> wrote: > [..] > > > >> > However, trying to quickly summarize how that would work (for who is > >> > already somewhat familiar with reclaiming bits): > >> > > >> > - a task utilization contribution is accounted for (at rq level) as > >> > soon as it wakes up for the first time in a new period > >> > - its contribution is then removed after the 0lag time (or when the > >> > task gets throttled) > >> > - frequency transitions are triggered accordingly > >> > > >> > So, I don't see why triggering a go down request after the 0lag time > >> > expired and quickly reacting to tasks waking up would have create > >> > problems in your case? > >> > >> In my experience, the 'reacting to tasks' bit doesn't work very well. > > > > Humm.. but in this case we won't be 'reacting', we will be > > 'anticipating' tasks' needs, right? > > Are you saying we will start ramping frequency before the next > activation so that we're ready for it? >
I'm saying that there is no need to ramp, simply select the frequency that is needed for a task (or a set of them). > If not, it sounds like it will only make the frequency request on the > next activation when the Active bandwidth increases due to the task > waking up. By then task has already started to run, right? > When the task is enqueued back we select the frequency considering its bandwidth request (and the bandwidth/utilization of the others). So, when it actually starts running it will already have enough capacity to finish in time.
