Re: [PATCH] oops_in_progress is unlikely()

[Jamie Lokier]

Richard B. Johnson wrote:
> > 		cmpl	$1,%eax
> > 		jbe	1f
> > 		call	do_default
> > 	more_code:
> > 		.subsection 1
> > 	1:	jnz	2f
> > 		call	do_something_if_equal
> > 		jmp	more_code
> > 	2:	call	do_something_if_less
> > 		jmp	more_code
> > 		.previous
> >
> 
> You are a magician! Putting in a .subsection to hide the jump
> is absolute bullshit. The built-in macros, ".subsection", and
> ".previous" just made the damn linker do the fixup. You just
> did a long jump, out of the current code-stream, into some
> other section. Then you jumped back. Hell of an optimization!

".subsection" does not create jump instructions.  The linker does not
create jump instructions.  The only jump instructions are the ones
written in the source code.

The above code will execute three instructions in the do_default case:
"cmpl", "jbe" and "call".  No jumps are taken in that case.

The code does exactly what you said is logically impossible: one of
the cases, presumably marked "likely" in C code, takes no jumps at
all.  What the other cases do is irrelevant.  That is called
optimising for the likely case, at the expense of the others.

Try assembling the above source, with a "ret" after it, and then
disassemble the object file, if you don't believe me.

Or just read Pavel's example.

If you don't understand Pavel's example, there is no hope of you
grokking the advanced stuff ;)

Seriously, you can't possibly have done asm programming for 30
years without optimising for fast paths... surely?

> Linker tricks won't work for me.

You'll be glad to know GCC does it without linker tricks.

> Also, putting some address on the stack and executing 'ret' emulate
> a jump won't impress me either.

It shouldn't.  That would misalign the RSB (return stack buffer:
target prediction for "ret") causing several subsequent "ret"
instructions to mispredict their targets and stall the pipeline.

-- Jamie
-
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/