Re: [PATCH] tracing: Cleanup the convoluted softirq tracepoints

[H. Peter Anvin]

On 10/21/2010 12:56 PM, Thomas Gleixner wrote:
> On Thu, 21 Oct 2010, Steven Rostedt wrote:
> 
>> On Thu, 2010-10-21 at 18:18 +0200, Thomas Gleixner wrote:
>>>
>>> On Tue, 19 Oct 2010, Steven Rostedt wrote:
>>>
>>>> On Wed, 2010-10-20 at 00:04 +0200, Thomas Gleixner wrote:
>>>>
>>>>> hpa just posted code which does the _RIGHT_ _THING_ independent of any
>>>>> compiler madness and you tracer folks just missed it.
>>>>
>>>> Thomas,
>>>>
>>>> Can you try this patch and see if it makes the object code better?
>>>
>>> Nope, same result.
>>
>> Yeah, I figured. Do you have CC_OPTIMIZE_FOR_SIZE set? And if you do,
>> what happens if you disable it?
> 
> Hmm. Indeed. That gets rid of the double jump.
> 

-Os unfortunately drops a bunch of optimizations.

With gcc 4.5.1 there is actually a way to guarantee to get rid of double
jumps, which is that you tell gcc that it is branching to one of two
targets:

                asm goto("1: .byte 0xe9 ; .long %l[t_no]-2f\n"
			 "2:\n"
		         /* patching infrastructure goes here */
                         : : "i" (bit) : : t_no, t_yes);
	        __builtin_unreachable();
t_no:
                return false;
t_yes:
                return true;

[The open-coding of the jump is necessary to force the 5-byte form
instead of the 2-byte form.]

The patching machinery can recognize the case where the jump offset is
zero and patch in a NOP instead.

There does, however, seem to be a couple of problems:

a) gcc 4.5.1 is required due to a bug in previous versions of gcc when
an asm goto doesn't have a fallthrough case.

b) it seems to encourage gcc to actively jump around as it reorders
blocks, since gcc no longer sees a fallthrough case at all.

Not sure I have a good solution for this, at least not with current gcc.

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