From: Peter Zijlstra <peterz@infradead.org>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: Tejun Heo <tj@kernel.org>, Xuewen Yan <xuewen.yan@unisoc.com>,
mingo@redhat.com, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, lukasz.luba@arm.com,
linux-kernel@vger.kernel.org, rui.zhang@intel.com,
di.shen@unisoc.com, ke.wang@unisoc.com, xuewen.yan94@gmail.com,
Marco Elver <elver@google.com>
Subject: Re: [RFC PATCH] sched: Add scx_cpuperf_target in sched_cpu_util()
Date: Thu, 19 Mar 2026 12:12:41 +0100 [thread overview]
Message-ID: <20260319111241.GG3738786@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CAFULd4Ycw=EEixkGCaCkrFC73kot2DMVPyde2yBHMkL2FZ4M0A@mail.gmail.com>
On Thu, Mar 19, 2026 at 12:02:29PM +0100, Uros Bizjak wrote:
> On Thu, Mar 19, 2026 at 11:27 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Thu, Mar 19, 2026 at 11:01:03AM +0100, Uros Bizjak wrote:
> > > On Thu, Mar 19, 2026 at 10:02 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > > That fastpath is definitely better; the slowpath is worse, but that is
> > > > in part because the compilers are stupid and cannot eliminate
> > > > static_branch().
> > >
> > > asm gotos are implicitly volatile because they are control flow
> > > primitives. The compiler will *not* remove them.
> >
> > Yes, but I want ponies ;-)
> >
> > if (static_branch_unlikely(&foo)) {
> > if (static_branch_unlikely(&foo)) {
> > /* A */
> > } else {
> > /* B */
> > }
> > /* C */
> > }
> >
> > Is a very common occurence. And we all know this really should be:
> >
> > if (static_branch_unlikely(&foo)) {
> > /* A */
> > /* C */
> > }
> >
> > So how can we make this happen? IMO marking those functions __const
> > should tell the compiler that yes, it can elimintate them.
>
> Huh, __const promises that the function does not access global memory
> and that the function does not have side effects other than returning
> a value. asm volatile inside the __const function creates a side
> effect, so removing function calls would be considered a
> misoptimization. Probably this could lead to undefined behavior in
> terms of what the compiler expects from a __const function.
So since the whole function reduces to a single branch or nop, it does
not in fact access memory or have side effects, right?
(and there is still __pure, for if we somehow consider the key governing
the text patching to be an 'access' in this case)
> > You should not try and protect the user. If they use __const
> > incorrectly, they get to keep the pieces and all that.
>
> I'm afraid that here the user wants the "__const with only partial
> properties of __const" function, where the compiler does not know what
> the user really wants.
Well, clearly I'm not a compiler person :-) I just want to be able to
tell the compiler that it can collapse these branches. Do you have
another option that would be less offensive to compiler folks such as
yourself?
next prev parent reply other threads:[~2026-03-19 11:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 12:17 [RFC PATCH] sched: Add scx_cpuperf_target in sched_cpu_util() Xuewen Yan
2026-03-18 12:47 ` Peter Zijlstra
2026-03-18 12:55 ` Vincent Guittot
2026-03-18 13:44 ` Qais Yousef
2026-03-19 2:13 ` Xuewen Yan
2026-03-19 7:09 ` Vincent Guittot
2026-03-19 10:18 ` Lukasz Luba
2026-03-24 1:32 ` Qais Yousef
2026-03-18 13:03 ` [PATCH] sched/cpufreq: Reorder so non-SCX is common path Christian Loehle
2026-03-19 1:08 ` [RFC PATCH] sched: Add scx_cpuperf_target in sched_cpu_util() Tejun Heo
2026-03-19 2:24 ` Xuewen Yan
2026-03-19 2:38 ` Xuewen Yan
2026-03-19 9:02 ` Peter Zijlstra
2026-03-19 10:01 ` Uros Bizjak
2026-03-19 10:26 ` Peter Zijlstra
2026-03-19 11:02 ` Uros Bizjak
2026-03-19 11:12 ` Peter Zijlstra [this message]
2026-03-19 11:19 ` Uros Bizjak
2026-03-19 11:33 ` Peter Zijlstra
2026-03-19 11:22 ` Peter Zijlstra
2026-03-18 12:54 ` Christian Loehle
2026-03-19 1:21 ` Tejun Heo
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=20260319111241.GG3738786@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bsegall@google.com \
--cc=di.shen@unisoc.com \
--cc=dietmar.eggemann@arm.com \
--cc=elver@google.com \
--cc=juri.lelli@redhat.com \
--cc=ke.wang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=rui.zhang@intel.com \
--cc=tj@kernel.org \
--cc=ubizjak@gmail.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xuewen.yan94@gmail.com \
--cc=xuewen.yan@unisoc.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