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

[Peter Zijlstra]

On Thu, Mar 19, 2026 at 12:12:42PM +0100, Peter Zijlstra wrote:
> 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@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.
> 
> 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)

So is it really just the problem that since the compiler doesn't know
what asm volatile ends up doing, it must assume the worse and hence
invalidates the __const (without a warning even).

So you're letting the unknown weight heavier than the explicit
instruction from the author who put on __const (and supposedly does
know).

And I feel somewhat strongly that this is wrong.

Yes, if the author gets it wrong, and there are side effects and things
are elided it is a misoptimization, but that is on the author. You can't
blame the compiler for doing what it was told to do.

Or is there really more to this?