On Fri, 22 Jun 2018 at 15:54, Vincent Guittot <vincent.guit...@linaro.org> wrote: > > On Fri, 22 Jun 2018 at 15:26, Peter Zijlstra <pet...@infradead.org> wrote: > > > > On Fri, Jun 22, 2018 at 02:23:22PM +0200, Vincent Guittot wrote: > > > On Fri, 22 Jun 2018 at 13:37, Peter Zijlstra <pet...@infradead.org> wrote: > > > > I suppose we can make it more complicated, something like: > > > > > > > > u u > > > > f := u + (--- - u) * (---)^n > > > > 1-r 1-r > > > > > > > > Where: u := cfs util > > > > r := \Sum !cfs util > > > > f := frequency request > > > > > > > > That would still satisfy all criteria I think: > > > > > > > > r = 0 -> f := u > > > > u = (1-r) -> f := 1 > > > > > > > > and in particular: > > > > > > > > u << (1-r) -> f ~= u > > > > > > > > which casuses less inflation than the linear thing where there is idle > > > > time. > > > > > And we are not yet at the right value for quentin's example as we need > > > something around 0.75 for is example > > > > $ bc -l > > define f (u,r,n) { return u + ((u/(1-r)) - u) * (u/(1-r))^n; } > > f(.2,.7,0) > > .66666666666666666666 > > f(.2,.7,2) > > .40740740740740740739 > > f(.2,.7,4) > > .29218106995884773661 > > > > So at 10% idle time, we've only inflated what should be 20% to 40%, that > > is entirely reasonable I think. The linear case gave us 66%. But feel > > free to increase @n if you feel that helps, 4 is only one mult more than > > 2 and gets us down to 29%. > > I'm a bit lost with your example. > u = 0.2 (for cfs) and r=0.7 (let say for rt) in your example and idle is 0.1 > > For rt task, we run 0.7 of the time at f=1 then we will select f=0.4 > for run cfs task with u=0.2 but u is the utilization at f=1 which > means that it will take 250% of normal time to execute at f=0.4 which > means 0.5 time instead of 0.2 at f=1 so we are going out of time. In > order to have enough time to run r and u we must run at least f=0.666 > for cfs = 0.2/(1-0.7). If rt task doesn't run at f=1 we would have to > run at f=0.9 > > > > > > The non linearity only comes from dl so if we want to use the equation > > > above, u should be (cfs + rt) and r = dl > > > > Right until we allow RT to run at anything other than f=1. Once we allow > > rt util capping, either through Patrick's thing or CBS servers or > > whatever, we get: > > > > f = min(1, f_rt + f_dl + f_cfs) > > > > And then u_rt does want to be part of r. And while we do run RT at f=1, > > it doesn't matter either way around I think. > > > > > But this also means that we will start to inflate the utilization to > > > get higher OPP even if there is idle time and lost the interest of > > > using dl bw > > > > You get _some_ inflation, but only if there is actual cfs utilization to > > begin with. > > > > And that is my objection to that straight sum thing; there the dl util > > distorts the computed dl bandwidth thing even if there is no cfs > > utilization. > > hmm,
forgot to finish this sentence hmm, dl util_avg is only used to detect is there is idle time so if cfs util is nul we will not distort the dl bw (for a use case where there is no rt task running) > > > >