From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: "hongyan.xia(夏弘彦)" <hongyan.xia@transsion.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Juri Lelli" <juri.lelli@redhat.com>,
"Vincent Guittot" <vincent.guittot@linaro.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Ben Segall" <bsegall@google.com>, "Mel Gorman" <mgorman@suse.de>,
"Valentin Schneider" <vschneid@redhat.com>,
"K Prateek Nayak" <kprateek.nayak@amd.com>
Cc: "hupu(胡璞)" <hupu@transsion.com>,
"jiazi.li(李甲子)" <jiazi.li@transsion.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched/fair: Revert boost in cpu_util()
Date: Tue, 26 May 2026 19:16:45 +0200 [thread overview]
Message-ID: <d6b41012-923b-4d0e-bc31-42dd74033d3e@arm.com> (raw)
In-Reply-To: <20260518024039.932-1-hongyan.xia@transsion.com>
On 18.05.26 04:40, hongyan.xia(夏弘彦) wrote:
> From: Hongyan Xia <hongyan.xia@transsion.com>
>
> We have seen a massive power consumption regression (20% SoC power
> increase in many apps) after updating our kernel. After bisection we
> pinpointed the regression to the cpu_util(boost) feature. After
> reverting the boost feature the massive energy regression is gone.
> Detailed trace analysis down below. The regression is found across quite
> many apps but Youtube is one of the worst offenders, shown in the
> 1080p60fps video benchmark:
>
> Setup FPS SoC Power (mW) diff
> w/ boost 59.94 913.6
> w/o boost 59.93 720.4 -21.15%
>
> Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com>
Looks like I missed running one of the low-power test cases back then.
That said, boosting tasks under contention does not seem like a
particularly good idea.
Jankbench, being primarily a UI rendering benchmark, was probably
overemphasizing stress on the Android Graphics Pipeline (AGP), where the
runnable_avg boosting happened to help. Support for Jankbench also
appears to have stopped with Android 12 — I am not sure why.
At the same time, low-power benchmarks, and even games, do not seem to
have equally strict requirements for consistently meeting UI rendering
deadlines.
It is also possible that the AGP itself has evolved since then. I
vaguely remember a Google Bootcamp presentation discussing the injection
of performance hints at the beginning of a frame-rendering cycle to
mitigate early jank, but I can no longer find it. I also do not know how
that approach relates to the removal of all vendor hooks.
Given all of this, I would also lean toward removing the runnable_avg
boosting functionality entirely, rather than keeping it behind a sched
feature flag that defaults to false.
> @@ -8229,16 +8222,10 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target)
> * Return: (Boosted) (estimated) utilization for the specified CPU.
s/(Boosted) (e/(E/
> */
> static unsigned long
> -cpu_util(int cpu, struct task_struct *p, int dst_cpu, int boost)
> +cpu_util(int cpu, struct task_struct *p, int dst_cpu)
> {
> struct cfs_rq *cfs_rq = &cpu_rq(cpu)->cfs;
> unsigned long util = READ_ONCE(cfs_rq->avg.util_avg);
> - unsigned long runnable;
> -
> - if (boost) {
> - runnable = READ_ONCE(cfs_rq->avg.runnable_avg);
> - util = max(util, runnable);
> - }
>
> /*
> * If @dst_cpu is -1 or @p migrates from @cpu to @dst_cpu remove its
next prev parent reply other threads:[~2026-05-26 17:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 2:40 hongyan.xia(夏弘彦)
2026-05-18 10:04 ` Christian Loehle
2026-05-18 11:37 ` hongyan.xia(夏弘彦)
2026-05-19 1:17 ` Qais Yousef
2026-05-19 2:41 ` hongyan.xia(夏弘彦)
2026-05-19 13:30 ` Qais Yousef
2026-05-26 7:35 ` Hongyan Xia
2026-05-22 7:49 ` Dietmar Eggemann
2026-05-22 9:36 ` hongyan.xia
2026-05-26 17:16 ` Dietmar Eggemann
2026-05-27 3:18 ` Hongyan Xia
2026-05-26 17:16 ` Dietmar Eggemann [this message]
2026-05-28 1:41 ` Hongyan Xia
2026-06-04 6:53 ` Hongyan Xia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d6b41012-923b-4d0e-bc31-42dd74033d3e@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=bsegall@google.com \
--cc=hongyan.xia@transsion.com \
--cc=hupu@transsion.com \
--cc=jiazi.li@transsion.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®