Messages in this thread | | | Date | Mon, 17 Oct 2022 14:49:49 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH bpf-next v2 0/4] Add ftrace direct call for arm64 |
| |
On Mon, 17 Oct 2022 19:55:06 +0200 Florent Revest <revest@chromium.org> wrote:
> Note that I can't really make sense of the perf report with indirect > calls. it always reports it spent 12% of the time in > rethook_trampoline_handler but I verified with both a WARN in that > function and a breakpoint with a debugger, this function does *not* > get called when running this "bench trig-fentry" benchmark. Also it > wouldn't make sense for fprobe_handler to call it so I'm quite > confused why perf would report this call and such a long time spent > there. Anyone know what I could be missing here ?
The trace shows __bpf_prog_exit, which I'm guessing is tracing the end of the function. Right?
In which case I believe it must call rethook_trampoline_handler:
-> fprobe_handler() /* Which could use some "unlikely()" to move disabled paths out of the hot path */
/* And also calls rethook_try_get () which does a cmpxchg! */
-> ret_hook() -> arch_rethook_prepare() Sets regs->lr = arch_rethook_trampoline
On return of the function, it jumps to arch_rethook_trampoline()
-> arch_rethook_trampoline() -> arch_rethook_trampoline_callback() -> rethook_trampoline_handler()
So I do not know how it wouldn't trigger the WARNING or breakpoint if you added it there.
-- Steve
| |