Message-ID: <CAKfTPtA+QwUL5c0kqacEYtqONem6_PedMcmq0PAb0RQbi_bRjQ@mail.gmail.com>
Date:   Fri, 22 Jun 2018 15:54:24 +0200
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Quentin Perret <quentin.perret@....com>,
        Ingo Molnar <mingo@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Juri Lelli <juri.lelli@...hat.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Morten Rasmussen <Morten.Rasmussen@....com>,
        viresh kumar <viresh.kumar@...aro.org>,
        Valentin Schneider <valentin.schneider@....com>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH v6 04/11] cpufreq/schedutil: use rt utilization tracking

On Fri, 22 Jun 2018 at 15:26, Peter Zijlstra <peterz@...radead.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 <peterz@...radead.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,


>

Powered by blists - more mailing lists