Re: [RFC][PATCH 3/2] x86/jump labels: Count and display the shortjumps used

[Steven Rostedt]

On Wed, 2013-08-07 at 12:49 -0700, Linus Torvalds wrote:
> On Wed, Aug 7, 2013 at 12:27 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> > Well we do... both to extract relocations and to sort the exception table.  Perhaps we need to merge those kinds of postprocessing tools?
> 
> If we can do this generically and without adding 500 lines of
> specialized code, my argument obviously goes away.

And the code that does this work is actually in the kernel today,
although, seldom used.

The recordmount.[ch] can do this modification. It's main purpose was to
create a table of mcount call locations that ftrace can use to convert
to nops on boot. As it only converts white-listed sections (doesn't
convert things like .init or .exit, as there exists no way today to
generically know when they are removed), it only creates the pointers to
those sections that ftrace will touch.

Those sections that do not get converted, can have a call to mcount that
is not changed to a nop. Most places this is not the case, because
things like __init have "notrace" defined to keep those functions from
being profiled. But if another section is added that ftrace does not
know about, it will get a call to mcount and cause a bit of a slow down.
Note, mcount itself looks like:

mcount:
	retq

To handle these missed cases, the recordmcount.c was modified to convert
the call to mcount into a nop. There's a flag you can set to have this
warn on locations that it converts:

make RECORDMCOUNT_WARN=1

It will give a warning at the locations that it converted, which should
then be white-listed or have notrace added to it.

This is the code I based the update_jump_labels from. With a bit of
work, all these ELF parsers could probably be consolidated, and this
addition may not be that hard or complex to add.

-- Steve


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