On Thu, Oct 22, 2020 at 09:35:10AM -0400, Steven Rostedt wrote:
> On Thu, 22 Oct 2020 10:21:22 +0200
> Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
>
> > hi,
> > this patchset tries to speed up the attach time for trampolines
> > and make bpftrace faster for wildcard use cases like:
> >
> > # bpftrace -ve "kfunc:__x64_sys_s* { printf("test\n"); }"
> >
> > Profiles show mostly ftrace backend, because we add trampoline
> > functions one by one and ftrace direct function registering is
> > quite expensive. Thus main change in this patchset is to allow
> > batch attach and use just single ftrace call to attach or detach
> > multiple ips/trampolines.
>
> The issue I have with this change is that the purpose of the direct
> trampoline was to give bpf access to the parameters of a function as if it
> was called directly. That is, it could see the parameters of a function
> quickly. I even made the direct function work if it wanted to also trace
> the return code.
>
> What the direct calls is NOT, is a generic tracing function tracer. If that
> is required, then bpftrace should be registering itself with ftrace.
> If you are attaching to a set of functions, where it becomes obvious that
> its not being used to access specific parameters, then that's an abuse of
> the direct calls.
>
> We already have one generic function tracer, we don't need another.
I understand direct calls as a way that bpf trampolines and ftrace can
co-exist together - ebpf trampolines need that functionality of accessing
parameters of a function as if it was called directly and at the same
point we need to be able attach to any function and to as many functions
as we want in a fast way
the bpftrace example above did not use arguments for simplicity, but they
could have been there ... I think we could detect arguments presence in
ebpf programs and use ftrace_ops directly in case they are not needed
jirka
