Kernel Recipes 2019 - ftrace: Where modifying a running kernel all started

Ftrace’s most powerful feature is the function tracer (and function graph tracer which is built from it). But to have this enabled on production systems, it had to have its overhead be negligible when disabled. As the function tracer uses gcc’s profiling mechanism, which adds a call to “mcount” (or more recently fentry, don’t worry if you don’t know what this is, it will all be explained) at the start of almost all functions, it had to do something about the overhead that causes. The solution was to turn those calls into “nops” (an instruction that the CPU simply ignores). But this was no easy feat. It took a lot to come up with a solution (and also turning a few network cards into bricks). This talk will explain the history of how ftrace came about implementing the function tracer, and brought with it the possibility of static branches and soon static calls!
Steven Rostedt

[@MarsCheng]

thanks, this is a great talk!! I finally realize a tool I use a lot everyday. :-)

[@danielyaacovbilar3537]

Very informative talk w a great finish. Q: at ca 22:20 Steven says that Intel was reluctant to confirm that the breakpoint synchronization primitive solution would work, they were cagey for several years. Would you have any insights as to why?

[@systemloc]

They probably didn't actually know and it could be very complex to sit down and step through all of the parts of the processor to verify that it's verifiably correct in all situations.