Re: [PATCH v6 04/11] cpufreq/schedutil: use rt utilization tracking

[Vincent Guittot]

On Fri, 22 Jun 2018 at 15:54, Vincent Guittot
<vincent.guittot@xxxxxxxxxx> wrote:
>
> On Fri, 22 Jun 2018 at 15:26, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > On Fri, Jun 22, 2018 at 02:23:22PM +0200, Vincent Guittot wrote:
> > > On Fri, 22 Jun 2018 at 13:37, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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)

>
>
> >