Re: [PATCH 00/10] jump label: introduce very_[un]likely + cleanups + docs

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 2012-02-22 at 14:34 +0100, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > I like the blue shed, but anyway...
> > 
> > On Wed, 2012-02-22 at 09:06 +0100, Ingo Molnar wrote:
> > > * H. Peter Anvin <hpa@zytor.com> wrote:
> > > 
> > > > Not arguing that, but the static aspect is still key... or 
> > > > people will read it as another version of likely/unlikely.  
> > > 
> > > They can *read* it as such, that as is very much intentional! 
> > 
> > I mentioned this thread on irc and the first comment I received was:
> > 
> > "is that a new attempt at trying to guide the compiler?"
> 
> It essentially is, implemented partly via compiler help, 
> combined with runtime code patching, as an extended run-time arm 
> of the compiler in essence, to make out of line slowpaths even 
> cheaper to have around - to make the fast-path even faster.

Actually, I was partly under the impression that we didn't care if it
was in the fast path. Maybe we need three versions. Let me explain.

We have cases where we want it default disabled and the code called when
enabled should be as out of line as possible. Tracing definitely falls
in this pattern. But we could push a "unlikely(static_branch())" for
such a case (or keep it as very_unlikely()).

Then we have cases where it is default enabled, where we can insert the
code in the fast path. Or do we even care how the compiler places it?
Because this leads us to the third use...

The third use is the case were we don't know the branch should be taken
or not until boot. We don't want the compiler to optimize the paths at
all. This example is for things like CPU features or types (as HPA
explained the "if (very_unlikely(cpu_vendor_amd))". This is the category
that we want to have an efficient system for the running hardware. We
can't bias one way or the other at compile time because frankly, we
don't know the answer until run time. This could also be used by modules
that are drivers for several types of hardware, and it can dynamically
change itself to suit the hardware it is driving.

> 
> > I personally find the very_unlikely() confusing, but then 
> > again I like the blue shed over the pink one.
> 
> Confusing in what way?

Because it really just looks like a stronger "unlikely()" and
fundamentally it really isn't. For tracing, sure that can be the way we
look at it, but for the more general case, it is a "We don't know which
way this branch should go most of the time, lets just pick one then
optimize later".

Again, maybe we need a "very_unlikely()" for the tracing case, maybe
even a "very_likely()", but then keep a static_branch() or whatever for
those cases you do not want to optimize at compile time.

-- Steve