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

[Ingo Molnar]

* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> On Wed, 2012-02-22 at 14:34 +0100, Ingo Molnar wrote:
> > * Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > 
> > > I like the blue shed, but anyway...
> > > 
> > > On Wed, 2012-02-22 at 09:06 +0100, Ingo Molnar wrote:
> > > > * H. Peter Anvin <hpa@xxxxxxxxx> 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...

These two variants cover all current uses of jump labels.

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

Well, the fact is that right now it *is* a stronger unlikely() 
on architectures that have jump-labels and it's mapped to 
unlikely() on others.

> [...] 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".

That's not how it's used by the scheduler or by perf - and by 
the looks of it that's not how the networking code uses it 
either.

I tend to concentrate on the common case.

> Again, maybe we need a "very_unlikely()" for the tracing case,

... and that's the usecase for the scheduler, for events and for 
networking. I.e. all current usecases in the kernel.

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

Once such uses arise maybe we could add such an 'unbiased' 
variant.

But the reality is that today jump labels are used for critical 
codepaths that don't want to slow themselves down due to some 
rare feature that is commonly off: this is how tracing, the 
scheduler, perf events and networking uses jump labels.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/