Messages in this thread | | | Date | Tue, 19 Oct 2010 21:52:27 -0400 | From | Jason Baron <> | Subject | Re: [PATCH] tracing: Cleanup the convoluted softirq tracepoints |
| |
On Tue, Oct 19, 2010 at 09:36:30PM -0400, Steven Rostedt wrote: > > On Wed, 2010-10-20 at 00:17 +0200, Thomas Gleixner wrote: > > On Tue, 19 Oct 2010, Thomas Gleixner wrote: > > > On Tue, 19 Oct 2010, Jason Baron wrote: > > > > > Now even worse, when you NOP out the jmpq then your tracepoint is > > > > > still not enabled. Brilliant ! > > > > > > > > > > > > > The 'jmpq' in the enabled case is patched with a jmpq to the body of the > > > > tracepoint itself. > > > > > > Brilliant. > > > > IOW, We now jump around the jump which jumps around the disabled code. > > > > > Do you happen to have CONFIG_CC_OPTIMIZE_FOR_SIZE set? If so, then this > is a known issue. We even originally had jump label enabled _only_ if > CC_OPTIMIZE_FOR_SIZE was not set, but hpa NAK'd it. > > http://lkml.org/lkml/2010/9/22/482 > > http://lkml.org/lkml/2010/9/20/488 > > http://lkml.org/lkml/2010/9/24/259 > > -- Steve
thanks Steve. I was about to say this. When CONFIG_CC_OPTIMIZE_FOR_SIZE is not set we don't get the double 'jmp' and the tracepoint code is moved out of line. It was mentioned that a number of distros ship with CONFIG_CC_OPTIMIZE_FOR_SIZE not set, and as Steve mentioned my original patch set was conditional on !CONFIG_CC_OPTIMIZE_FOR_SIZE.
using hot/cold labels gcc can fix the CONFIG_CC_OPTIMIZE_FOR_SIZE case, but its a non-trivial amount of work for gcc. I was hoping that if jump labels are included, we could make the gcc work happen.
thanks,
-Jason
| |