Messages in this thread | | | Date | Tue, 23 May 2017 22:29:56 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection |
| |
On Tue, May 23, 2017 at 10:23:21PM +0200, Peter Zijlstra wrote: > On Tue, May 23, 2017 at 09:53:43AM +0100, Juri Lelli wrote: > > > A point that is still very much up for discussion (more that the others :) is > > how we implement frequency/cpu scaling. SCHED_FLAG_RECLAIM tasks only need > > grub_reclaim(), as the function already scales their reservation runtime > > considering other reservations and maximum bandwidth a CPU has to offer. > > However, for normal !RECLAIM tasks multiple things can be implemented which > > seem to make sense: > > > > - don't scale at all: normal tasks will only get a % of CPU _time_ as granted > > by AC > > - go to max as soon as a normal task in enqueued: this because dimensioning of > > parameters is usually done at max OPP/biggest CPU and normal task assume > > that this is always the condition when they run > > - scale runtime acconding to current frequency and max CPU capacity: this is > > what this set is currently implementing > > > > Opinions? > > > 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).
When all DL tasks consume their full reservation.
> So !RECLAIM works as expected. They get the time they reserved, since > that was taken into account by active bandwidth. > > And RECLAIM works, since that only promises to (re)distribute idle time, > and if there is none that is an easy task.
And if they don't, there will thus be some idle time to redistribute and that, again, still works as expected.
| |