Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <b477ac75a2b163048bdaeb37f57b4c3f04f75a31.1559631700.git.viresh.kumar@linaro.org>
 <20190605091644.w3g7hc7r3eiscz4f@queper01-lin> <20190606025204.qe5v7j6fysjkgxc6@vireshk-i7>
 <20190617150204.GG3436@hirez.programming.kicks-ass.net> <20190618031217.63md32da5pzydqia@vireshk-i7>
 <CAJZ5v0g4shiz+Hq+0fS1GQjQX7tK5EyLiX-SOpDoTm4xswV8bg@mail.gmail.com> <20190618074728.gf6wugkbndhhcqql@vireshk-i7>
In-Reply-To: <20190618074728.gf6wugkbndhhcqql@vireshk-i7>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Tue, 18 Jun 2019 10:10:48 +0200
Message-ID: <CAJZ5v0hi_zXPWqMS_VFnrbs8=BZbhcQRzm6B7fNZYWTXQhA3Mw@mail.gmail.com>
Subject: Re: [PATCH] sched/fair: Introduce fits_capacity()
To:     Viresh Kumar <viresh.kumar@linaro.org>
Cc:     "Rafael J. Wysocki" <rafael@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Quentin Perret <quentin.perret@arm.com>,
        Ingo Molnar <mingo@redhat.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Vincent Guittot <vincent.guittot@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jun 18, 2019 at 9:47 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 18-06-19, 09:26, Rafael J. Wysocki wrote:
> > On Tue, Jun 18, 2019 at 5:12 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > >
> > > +Rafael
> > >
> > > On 17-06-19, 17:02, Peter Zijlstra wrote:
> > > > On Thu, Jun 06, 2019 at 08:22:04AM +0530, Viresh Kumar wrote:
> > > > > Hmm, even if the values are same currently I am not sure if we want
> > > > > the same for ever. I will write a patch for it though, if Peter/Rafael
> > > > > feel the same as you.
> > > >
> > > > Is it really the same variable or just two numbers that happen to be the
> > > > same?
> > >
> > > In both cases we are trying to keep the load under 80% of what can be supported.
> > > But I am not sure of the answer to your question.
> > >
> > > Maybe Rafael knows :)
> >
> > Which variable?
>
> Schedutil multiplies the target frequency by 1.25 (20% more capacity eventually)
> to get enough room for more load and similar thing is done in fair.c at several
> places to see if the new task can fit in a runqueue without overloading it.

For the schedutil part, see the changelog of the commit that introduced it:

9bdcb44e391d cpufreq: schedutil: New governor based on scheduler
utilization data

As for the other places, I don't know about the exact reasoning.

> Quentin suggested to use common code for this calculation and that is what is
> getting discussed here.

I guess if the rationale for the formula is the same in all cases, it
would be good to consolidate that code and document the rationale
while at it.

Otherwise, I'm not sure.