[ Steve interrupts his time off ]
On Sat, 19 May 2018 17:49:38 -0700
"Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote:
> I suggested to Steven that the rcu_read_lock() and rcu_read_unlock() might
> be outside of the trampoline, but this turned out to be infeasible. Not
> that I remember why! ;-)
Because the trampoline itself is what needs to be freed. The trampoline
is what mcount/fentry or an optimized kprobe jumps to.
<func>:
nop
[ enable function tracing ]
<func>:
call func_tramp --> set up stack
call function_tracer()
pop stack
ret
^^^^^
This is the trampoline
There's no way to know when a task will be on the trampoline or not.
The trampoline is allocated, and we need RCU_tasks to know when we can
free it. The only way to make a "wrapper" is to modify more of the code
text to do whatever before calling the trampoline, which is
impractical.
The allocated trampolines were added as an optimization, where two
registered callback functions from ftrace that are attached to two
different functions don't call the same trampoline which would have to
do a loop and a hash lookup to know what callback to call per function.
If a callback is the only one attached to a specific function, then a
trampoline is allocated and will call that callback directly, keeping
the overhead down.
There is no feasible way to know when a task is on a trampoline
without adding overhead that negates the speed up we receive by making
individual trampolines to begin with.
-- Steve
[ Steve resumes his time off ]
