All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	Oleg Nesterov <oleg@redhat.com>, Jiri Olsa <jolsa@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	linux-api@vger.kernel.org, linux-man@vger.kernel.org,
	x86@kernel.org, bpf@vger.kernel.org,
	Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Borislav Petkov (AMD)" <bp@alien8.de>,
	Ingo Molnar <mingo@redhat.com>, Andy Lutomirski <luto@kernel.org>,
	"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	Deepak Gupta <debug@rivosinc.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCHv7 bpf-next 0/9] uprobe: uretprobe speed up
Date: Mon, 10 Jun 2024 11:16:14 -0400	[thread overview]
Message-ID: <20240610111614.1448e721@rorschach.local.home> (raw)
In-Reply-To: <CAEf4Bzbc99bwGcmtCa3iekXSvSrxMQzfnTViT5Y-dn8qbvJy7A@mail.gmail.com>

On Wed, 5 Jun 2024 09:42:45 -0700
Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:

> Another ping. It's been two weeks since Jiri posted the last revision
> that got no more feedback to be addressed and everyone seems to be
> happy with it.

Sorry, there's been a lot going on.

> 
> This is an important speed up improvement for uprobe infrastructure in
> general and for BPF ecosystem in particular. "Uprobes are slow" is one
> of the top complaints from production BPF users, and sys_uretprobe
> approach is significantly improving the situation for return uprobes
> (aka uretprobes), potentially enabling new use cases that previously
> could have been too expensive to trace in practice and reducing the
> overhead of the existing ones.
> 
> I'd appreciate the engagement from linux-trace maintainers on this
> patch set. Given it's important for BPF and that a big part of the
> patch set is BPF-based selftests, we'd also be happy to route all this
> through the bpf-next tree (which would actually make logistics for us
> much easier, but that's not the main concern). But regardless of the
> tree, it would be nice to make a decision and go forward with it.

I'll be talking with Masami about this later today.

-- Steve

  reply	other threads:[~2024-06-10 15:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-23 12:11 [PATCHv7 bpf-next 0/9] uprobe: uretprobe speed up Jiri Olsa
2024-05-23 12:11 ` [PATCHv7 bpf-next 1/9] x86/shstk: Make return uprobe work with shadow stack Jiri Olsa
2024-05-23 12:11 ` [PATCHv7 bpf-next 2/9] uprobe: Wire up uretprobe system call Jiri Olsa
2024-06-10 22:05   ` Masami Hiramatsu
2024-06-11  7:44     ` Jiri Olsa
2024-05-23 12:11 ` [PATCHv7 bpf-next 3/9] uprobe: Add uretprobe syscall to speed up return probe Jiri Olsa
2024-05-23 12:11 ` [PATCHv7 bpf-next 4/9] selftests/x86: Add return uprobe shadow stack test Jiri Olsa
2024-05-23 12:11 ` [PATCHv7 bpf-next 5/9] selftests/bpf: Add uretprobe syscall test for regs integrity Jiri Olsa
2024-05-23 12:11 ` [PATCHv7 bpf-next 6/9] selftests/bpf: Add uretprobe syscall test for regs changes Jiri Olsa
2024-05-23 12:11 ` [PATCHv7 bpf-next 7/9] selftests/bpf: Add uretprobe syscall call from user space test Jiri Olsa
2024-05-23 12:11 ` [PATCHv7 bpf-next 8/9] selftests/bpf: Add uretprobe shadow stack test Jiri Olsa
2024-06-10 22:02   ` Masami Hiramatsu
2024-05-23 12:11 ` [PATCHv7 9/9] man2: Add uretprobe syscall page Jiri Olsa
2024-05-31 17:52 ` [PATCHv7 bpf-next 0/9] uprobe: uretprobe speed up Andrii Nakryiko
2024-06-05 16:42   ` Andrii Nakryiko
2024-06-10 15:16     ` Steven Rostedt [this message]
2024-06-10 21:46     ` Masami Hiramatsu
2024-06-11  8:30       ` Andrii Nakryiko
2024-06-11 14:25         ` Masami Hiramatsu

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=20240610111614.1448e721@rorschach.local.home \
    --to=rostedt@goodmis.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bp@alien8.de \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=debug@rivosinc.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=songliubraving@fb.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    --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.