Messages in this thread | | | Date | Thu, 6 Jan 2022 00:24:35 +0900 | From | Masami Hiramatsu <> | Subject | Re: [RFC 00/13] kprobe/bpf: Add support to attach multiple kprobes |
| |
On Tue, 4 Jan 2022 09:09:30 +0100 Jiri Olsa <jolsa@redhat.com> 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@kernel.org>
| |