Re: [RFC PATCH] sched: Add scx_cpuperf_target in sched_cpu_util()

From: Uros Bizjak

Date: Thu Mar 19 2026 - 07:09:00 EST


On Thu, Mar 19, 2026 at 11:27 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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.

> 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.

Uros.