Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Date:   Sun, 10 Dec 2023 20:40:32 +0000
From:   Qais Yousef <qyousef@layalina.io>
To:     "Rafael J. Wysocki" <rafael@kernel.org>
Cc:     Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Viresh Kumar <viresh.kumar@linaro.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
        Lukasz Luba <lukasz.luba@arm.com>, Wei Wang <wvw@google.com>,
        Rick Yiu <rickyiu@google.com>,
        Chung-Kai Mei <chungkai@google.com>
Subject: Re: [PATCH v2 7/8] sched/schedutil: Add a new tunable to dictate
 response time
Message-ID: <20231210204032.fficzltp2gq66pne@airbuntu>
References: <20231208002342.367117-1-qyousef@layalina.io>
 <20231208002342.367117-8-qyousef@layalina.io>
 <CAJZ5v0iYUY-LrL3LNdMqxyMntBij_pkpETB2esYPraPekqtbhw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAJZ5v0iYUY-LrL3LNdMqxyMntBij_pkpETB2esYPraPekqtbhw@mail.gmail.com>
Precedence: bulk

On 12/08/23 19:06, Rafael J. Wysocki wrote:
> On Fri, Dec 8, 2023 at 1:24 AM Qais Yousef <qyousef@layalina.io> wrote:
> >
> > The new tunable, response_time_ms,  allow us to speed up or slow down
> > the response time of the policy to meet the perf, power and thermal
> > characteristic desired by the user/sysadmin. There's no single universal
> > trade-off that we can apply for all systems even if they use the same
> > SoC. The form factor of the system, the dominant use case, and in case
> > of battery powered systems, the size of the battery and presence or
> > absence of active cooling can play a big role on what would be best to
> > use.
> >
> > The new tunable provides sensible defaults, but yet gives the power to
> > control the response time to the user/sysadmin, if they wish to.
> >
> > This tunable is applied before we apply the DVFS headroom.
> >
> > The default behavior of applying 1.25 headroom can be re-instated easily
> > now. But we continue to keep the min required headroom to overcome
> > hardware limitation in its speed to change DVFS. And any additional
> > headroom to speed things up must be applied by userspace to match their
> > expectation for best perf/watt as it dictates a type of policy that will
> > be better for some systems, but worse for others.
> >
> > There's a whitespace clean up included in sugov_start().
> >
> > Signed-off-by: Qais Yousef (Google) <qyousef@layalina.io>
> 
> I thought that there was an agreement to avoid adding any new tunables
> to schedutil.

Oh. I didn't know that.

What alternatives do we have? I couldn't see how can we universally make the
response work for every possible system (not just SoC, but different platforms
with same SoC even) and workloads. We see big power saving with no or little
perf impact on many workloads when not applying the current 125%. Others want
to push it faster under gaming scenarios etc to get more stable FPS.

Hopefully uclamp will make the need for this tuning obsolete over time. But
until userspace gains critical mass; I can't see how we can know best
trade-offs for all myriads of use cases/systems.

Some are happy to gain more perf and lose power. Others prefer to save power
over perf. DVFS response time plays a critical role in this trade-off and I'm
not sure how we can crystal ball it without delegating.


Thanks!

--
Qais Yousef