All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@kernel.org>
To: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>
Cc: bpf@vger.kernel.org, Martin KaFai Lau <kafai@fb.com>,
	Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@chromium.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Viktor Malik <vmalik@redhat.com>
Subject: [PATCH RFC bpf-next 0/4] bpf: Add support to attach return prog in kprobe multi
Date: Wed,  7 Feb 2024 16:35:46 +0100	[thread overview]
Message-ID: <20240207153550.856536-1-jolsa@kernel.org> (raw)

hi,
adding support to attach both entry and return bpf program on single
kprobe multi link.

Having entry together with return probe for given function is common
use case for tetragon, bpftrace and most likely for others.

At the moment if we want both entry and return probe to execute bpf
program we need to create two (entry and return probe) links. The link
for return probe creates extra entry probe to setup the return probe.
The extra entry probe execution could be omitted if we had a way to
use just single link for both entry and exit probe.

In addition it's possible to control the execution of the return probe
with the return value of the entry bpf program. If the entry program
returns 0 the return probe is installed and executed, otherwise it's
skip.

I'm still working on the tetragon change, so I'll be sending non-RFC
version once that's ready, meanwhile any ideas and feedback on the
approach would be great.

The change in bpftrace [1] using the new interface shows speed increase
with tracing perf bench messaging:

  # perf bench sched messaging -l 100000

having system wide bpftrace:

  # bpftrace -e 'kprobe:ksys_write { }, kretprobe:ksys_write { }'

without bpftrace:

  # Running 'sched/messaging' benchmark:
  # 20 sender and receiver processes per group
  # 10 groups == 400 processes run

       Total time: 119.595 [sec]

   Performance counter stats for 'perf bench sched messaging -l 100000':

     102,419,967,282      cycles:u
   5,652,444,107,001      cycles:k
   5,782,645,019,612      cycles
      22,187,151,206      instructions:u                   #    0.22  insn per cycle
   2,979,040,498,455      instructions:k                   #    0.53  insn per cycle

       119.671169829 seconds time elapsed

        94.959198000 seconds user
      1815.371616000 seconds sys

with current bpftrace:

  # Running 'sched/messaging' benchmark:
  # 20 sender and receiver processes per group
  # 10 groups == 400 processes run

       Total time: 221.153 [sec]

   Performance counter stats for 'perf bench sched messaging -l 100000':

     125,292,164,504      cycles:u
  10,315,020,393,735      cycles:k
  10,501,379,274,042      cycles
      22,187,583,545      instructions:u                   #    0.18  insn per cycle
   4,856,893,111,303      instructions:k                   #    0.47  insn per cycle

       221.229234283 seconds time elapsed

       103.792498000 seconds user
      3432.643302000 seconds sys

with bpftrace using the new interface:

  # Running 'sched/messaging' benchmark:
  # 20 sender and receiver processes per group
  # 10 groups == 400 processes run

       Total time: 157.825 [sec]

   Performance counter stats for 'perf bench sched messaging -l 100000':

     102,423,112,279      cycles:u
   7,450,856,354,744      cycles:k
   7,584,769,726,693      cycles
      22,187,270,661      instructions:u                   #    0.22  insn per cycle
   3,985,522,383,425      instructions:k                   #    0.53  insn per cycle

       157.900787760 seconds time elapsed

        97.953898000 seconds user
      2425.314753000 seconds sys

thanks,
jirka


[1] https://github.com/bpftrace/bpftrace/pull/2984
---
Jiri Olsa (4):
      fprobe: Add entry/exit callbacks types
      bpf: Add return prog to kprobe multi
      libbpf: Add return_prog_fd to kprobe multi opts
      selftests/bpf: Add kprobe multi return prog test

 include/linux/fprobe.h                                       |  18 ++++++++++------
 include/uapi/linux/bpf.h                                     |   4 +++-
 kernel/trace/bpf_trace.c                                     |  50 ++++++++++++++++++++++++++++++++-----------
 tools/include/uapi/linux/bpf.h                               |   4 +++-
 tools/lib/bpf/bpf.c                                          |   1 +
 tools/lib/bpf/bpf.h                                          |   1 +
 tools/lib/bpf/libbpf.c                                       |   5 +++++
 tools/lib/bpf/libbpf.h                                       |   6 +++++-
 tools/testing/selftests/bpf/prog_tests/kprobe_multi_test.c   |  53 +++++++++++++++++++++++++++++++++++++++++++++
 tools/testing/selftests/bpf/progs/kprobe_multi_return_prog.c | 105 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 226 insertions(+), 21 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/progs/kprobe_multi_return_prog.c

             reply	other threads:[~2024-02-07 15:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-07 15:35 Jiri Olsa [this message]
2024-02-07 15:35 ` [PATCH RFC bpf-next 1/4] fprobe: Add entry/exit callbacks types Jiri Olsa
2024-02-13 15:35   ` Masami Hiramatsu
2024-02-15  9:08     ` Jiri Olsa
2024-02-07 15:35 ` [PATCH RFC bpf-next 2/4] bpf: Add return prog to kprobe multi Jiri Olsa
2024-02-08 19:05   ` Alexei Starovoitov
2024-02-10 15:29     ` Jiri Olsa
2024-02-07 15:35 ` [PATCH RFC bpf-next 3/4] libbpf: Add return_prog_fd to kprobe multi opts Jiri Olsa
2024-02-07 15:35 ` [PATCH RFC bpf-next 4/4] selftests/bpf: Add kprobe multi return prog test Jiri Olsa
2024-02-08 19:35 ` [PATCH RFC bpf-next 0/4] bpf: Add support to attach return prog in kprobe multi Andrii Nakryiko
2024-02-10 15:31   ` Jiri Olsa
2024-02-13  4:06     ` Andrii Nakryiko
2024-02-13 12:09       ` Jiri Olsa
2024-02-13 18:20         ` Andrii Nakryiko
2024-02-13 21:09           ` Jiri Olsa
2024-02-14 20:55             ` Jiri Olsa
2024-02-15 16:27               ` Steven Rostedt
2024-02-16 15:03                 ` Jiri Olsa
2024-02-19 11:20             ` Viktor Malik
2024-02-19 12:43               ` Jiri Olsa
2024-02-23  9:32         ` Jiri Olsa
2024-02-29  0:43           ` Andrii Nakryiko
2024-02-29  1:25             ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240207153550.856536-1-jolsa@kernel.org \
    --to=jolsa@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=mhiramat@kernel.org \
    --cc=sdf@google.com \
    --cc=songliubraving@fb.com \
    --cc=vmalik@redhat.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.