tracing: Process constants for (un)likely() profiler
authorSteven Rostedt (VMware) <rostedt@goodmis.org>
Tue, 17 Jan 2017 17:29:35 +0000 (12:29 -0500)
committerSteven Rostedt (VMware) <rostedt@goodmis.org>
Tue, 17 Jan 2017 20:13:05 +0000 (15:13 -0500)
commitd45ae1f7041ac52ade6c5ec76d96bbed765d67aa
tree902c94fd3caee27e8812eebb0591d10243fcb871
parent6496bb72bf20c1c7e4d6be44dfa663163e709116
tracing: Process constants for (un)likely() profiler

When running the likely/unlikely profiler, one of the results did not look
accurate. It noted that the unlikely() in link_path_walk() was 100%
incorrect. When I added a trace_printk() to see what was happening there, it
became 80% correct! Looking deeper into what whas happening, I found that
gcc split that if statement into two paths. One where the if statement
became a constant, the other path a variable. The other path had the if
statement always hit (making the unlikely there, always false), but since
the #define unlikely() has:

  #define unlikely() (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))

Where constants are ignored by the branch profiler, the "constant" path
made by the compiler was ignored, even though it was hit 80% of the time.

By just passing the constant value to the __branch_check__() function and
tracing it out of line (as always correct, as likely/unlikely isn't a factor
for constants), then we get back the accurate readings of branches that were
optimized by gcc causing part of the execution to become constant.

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
include/linux/compiler.h
kernel/trace/trace_branch.c