[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyu+3fRrsGUZkH6y5yND3oV9K+jCzrJyCWqwHQreFELOw@mail.gmail.com>
Date: Wed, 7 Aug 2013 13:47:34 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jason Baron <jbaron@...mai.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC][PATCH 3/2] x86/jump labels: Count and display the short
jumps used
On Wed, Aug 7, 2013 at 1:19 PM, Jason Baron <jbaron@...mai.com> wrote:
>
> The whole point of the thread started with wanting to move the default
> 'disabled' branch further out-of-line.
Yeah, but I always disagreed with that.
Putting the unusual code out-of-line (as in "at the end of the
function") is a good idea, but putting it *far* out of line (as in "in
a different section") likely makes little sense.
Now, the tracing code is admittedly specialized enough that we could
have some "really cold" attribute and move it to that kind of "even
further away" model, but most of the other uses of the static keys are
not necessarily of the kind where the non-default case is completely
or utterly unlikely - they want to use the static keys not because
some codepath is basically never taken, but because the code-path is
so critical that loading and testing a value from memory is considered
to be excessive for when the feature is turned off (ie scheduler
statistics etc).
So the code may not even be all that cold - some people may well run
with statistics enabled all the time - it's just that the non-enabled
case really *really* doesn't want to have the overhead of even
bothering to test for this event.
So I really think that a short jump would be a good thing, it's just
that I don't think it's *so* important that it's worth having several
hundreds of lines of code to support it.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists