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 current proposal keeps thing simple and doesn't take into account
the fact that rt runs at max freq which gives more margin when cfs is
running.
If we want to take into account the fact that rt task run at max freq
when computing frequency for dl and cfs we should use f = (cfs util +
dl bw) /(1 - rt util). Then this doesn't take into account the fact
that f=maw as soon as rt is runnable which means that dl can run at
max part of its time.

>
> >
> > > 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,
>
>
> >