On 08/10/2014 12:07 PM, Borislav Petkov wrote: > On Sun, Aug 10, 2014 at 05:45:15PM +0200, Ingo Molnar wrote: >> Indeed - but could we use that interface to cleanly expose the >> arch_static_branch_active() code you've written, or do we need new >> variants? > We could probably. > > The thing is, if we want to do the _active thing, the whole jump labels > infrastructure would need to know about those, let's call them "new > types" because they'd need different handling when enabling - see > __jump_label_transform() in arch/x86/kernel/jump_label.c with all the > NOP checks. > > Which begs the more important question: is adding those just to save us > a JMP penalty justify the additional code complexity. Frankly, I'm still > on the fence here and I'd rather do some perf measurements of a kernel > build with and without the JMP in native_sched_clock() to see whether it > is even noticeable or it disappears in the noise. > > Because if it does disappear, the whole trouble is just for nothing. > > Thanks. >
That is correct. We don't currently support having the default branch direction or the fast path be different from how the 'static_key' is initialized. If I understand your use-case correctly, you can't have the tsc path be the default *before* tsc_init() is called? If not, another thought on the implementation here might be to re-visit the work the Steven Rostedt proposed a while back, to use jump instead of no-ops by default, and then convert the jumps to no-ops in a post-processing phase in order to reduce code size (by having 2-byte jumps for example on x86). Potentially, we could then avoid converting some of the jumps, if they didn't match the default branch direction. See: http://www.serverphorums.com/read.php?12,759207 In that way there is no API change, we are just relaxing the restriction that the default branch direction must match the way that the keys are initialized. Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
