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>
