summaryrefslogtreecommitdiff
path: root/kernel/taskstats.c
diff options
context:
space:
mode:
authorSteven Rostedt (VMware) <rostedt@goodmis.org>2017-01-17 12:29:35 -0500
committerSteven Rostedt (VMware) <rostedt@goodmis.org>2017-01-17 15:13:05 -0500
commitd45ae1f7041ac52ade6c5ec76d96bbed765d67aa (patch)
tree902c94fd3caee27e8812eebb0591d10243fcb871 /kernel/taskstats.c
parent6496bb72bf20c1c7e4d6be44dfa663163e709116 (diff)
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>
Diffstat (limited to 'kernel/taskstats.c')
0 files changed, 0 insertions, 0 deletions