Re: [PATCH v7 0/9] Inefficient OPPs

From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Viresh Kumar <viresh.kumar@linaro.org>,
	Vincent Donnefort <vincent.donnefort@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Quentin Perret <qperret@google.com>,
	Linux PM <linux-pm@vger.kernel.org>,
	Ionela Voinescu <ionela.voinescu@arm.com>,
	Lukasz Luba <lukasz.luba@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Matthias Kaehlcke <mka@chromium.org>
Subject: Re: [PATCH v7 0/9] Inefficient OPPs
Date: Tue, 5 Oct 2021 16:34:22 +0200	[thread overview]
Message-ID: <CAJZ5v0g1S2+rXH7pZpZhG3ShZc1r5jpS=ham7BM3j6c0OncLaw@mail.gmail.com> (raw)
In-Reply-To: <20211004092508.tokhwodfa73terif@vireshk-i7>

On Mon, Oct 4, 2021 at 11:25 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 08-09-21, 15:05, Vincent Donnefort wrote:
> > Hi all,
> >
> > Here's the new version for the inefficient OPPs. This patch-set is based on the
> > following series from Viresh:
> >
> >   [PATCH V3 0/9] Add callback to register with energy model
> >   https://lore.kernel.org/linux-arm-msm/cover.1628742634.git.viresh.kumar@linaro.org/
> >
> > The main change in this version is the re-introduction of CPUFREQ_RELATION_E,
> > as a relation flag. When set, all relations will try to resolve a frequency
> > across efficient frequencies only.
> >
> > A bit of context:
> >
> > We (Power team in Arm) are working with an experimental kernel for the
> > Google's Pixel4 to evaluate and improve the current mainline performance
> > and energy consumption on a real life device with Android.
> >
> > The SD855 SoC found in this phone has several OPPs that are inefficient.
> > I.e. despite a lower frequency, they have a greater cost. (That cost being
> > fmax * OPP power / OPP freq). This issue is twofold. First of course,
> > running a specific workload at an inefficient OPP is counterproductive
> > since it wastes wasting energy. But also, inefficient OPPs make a
> > performance domain less appealing for task placement than it really is.
> >
> > We evaluated the change presented here by running 30 iterations of Android
> > PCMark "Work 2.0 Performance". While we did not see any statistically
> > significant performance impact, this change allowed to drastically improve
> > the idle time residency.
> >
> >
> >                            |   Running   |  WFI [1]  |    Idle   |
> >    ------------------------+-------------+-----------+-----------+
> >    Little cluster (4 CPUs) |    -0.35%   |   +0.35%  |   +0.79%  |
> >    ------------------------+-------------+-----------+-----------+
> >    Medium cluster (3 CPUs) |    -6.3%    |    -18%   |    +12%   |
> >    ------------------------+-------------+-----------+-----------+
> >    Big cluster    (1 CPU)  |    -6.4%    |    -6.5%  |    +2.8%  |
> >    ------------------------+-------------+-----------+-----------+
> >
> > On the SD855, the inefficient OPPs are found on the little cluster. By
> > removing them from the Energy Model, we make the most efficient CPUs more
> > appealing for task placement, helping to reduce the running time for the
> > medium and big CPUs. Increasing idle time is crucial for this platform due
> > to the substantial energy cost differences among the clusters. Also,
> > despite not appearing in the statistics (the idle driver used here doesn't
> > report it), we can speculate that we also improve the cluster idle time.
> >
> > [1] WFI: Wait for interrupt.
> >
> > Changelog since v6:
> >   - Bring back CPUFREQ_RELATION_E as a relation flag.
> >   - Make the policy min/max hard limits.
> >   - Remove the "efficient" member from the freq_table that was pointing to the
> >     next efficient frequency.
>
> Had a quick look, LGTM.
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

All patches in the series applied as 5.16 material, thanks!