Re: [RFC 00/13] kprobe/bpf: Add support to attach multiple kprobes

[Masami Hiramatsu]

On Tue,  4 Jan 2022 09:09:30 +0100
Jiri Olsa <jolsa@xxxxxxxxxx> wrote:

> hi,
> adding support to attach multiple kprobes within single syscall
> and speed up attachment of many kprobes.
> 
> The previous attempt [1] wasn't fast enough, so coming with new
> approach that adds new kprobe interface.

Yes, since register_kprobes() just registers multiple kprobes on
array. This is designed for dozens of kprobes.

> The attachment speed of of this approach (tested in bpftrace)
> is now comparable to ftrace tracer attachment speed.. fast ;-)

Yes, because that if ftrace, not kprobes.

> The limit of this approach is forced by using ftrace as attach
> layer, so it allows only kprobes on function's entry (plus
> return probes).

Note that you also need to multiply the number of instances.

> 
> This patchset contains:
>   - kprobes support to register multiple kprobes with current
>     kprobe API (patches 1 - 8)
>   - bpf support ot create new kprobe link allowing to attach
>     multiple addresses (patches 9 - 14)
> 
> We don't need to care about multiple probes on same functions
> because it's taken care on the ftrace_ops layer.

Hmm, I think there may be a time to split the "kprobe as an 
interface for the software breakpoint" and "kprobe as a wrapper
interface for the callbacks of various instrumentations", like
'raw_kprobe'(or kswbp) and 'kprobes'.
And this may be called as 'fprobe' as ftrace_ops wrapper.
(But if the bpf is enough flexible, this kind of intermediate layer
 may not be needed, it can use ftrace_ops directly, eventually)

Jiri, have you already considered to use ftrace_ops from the
bpf directly? Are there any issues?
(bpf depends on 'kprobe' widely?)

Thank you,

-- 
Masami Hiramatsu <mhiramat@xxxxxxxxxx>