From: Alexei Starovoitov <ast@plumgrid.com> To: Hekuang <hekuang@huawei.com> Cc: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@kernel.org>, Namhyung Kim <namhyung@kernel.org>, Arnaldo Carvalho de Melo <acme@infradead.org>, Jiri Olsa <jolsa@redhat.com>, Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>, Linux API <linux-api@vger.kernel.org>, Network Development <netdev@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, Peter Zijlstra <peterz@infradead.org>, "Eric W. Biederman" <ebiederm@xmission.com>, wangnan0@huawei.com Subject: Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Date: Sat, 14 Feb 2015 18:02:41 -0500 [thread overview] Message-ID: <CAMEtUuy42YvUVpecTcJpmqgmRQ=fpR3C+pTD0ij+R_5COYg6zQ@mail.gmail.com> (raw) On Wed, Feb 11, 2015 at 11:58 PM, Hekuang <hekuang@huawei.com> wrote: > >>> eBPF is very flexible, which means it is bound to have someone use it >>> in a way you never dreamed of, and that will be what bites you in the >>> end (pun intended). >> >> understood :) >> let's start slow then with bpf+syscall and bpf+kprobe only. > > > I think BPF + system calls/kprobes can meet our use case > (https://lkml.org/lkml/2015/2/6/44), but there're some issues to be > improved. > > I suggest that you can improve bpf+kprobes when attached to function > headers(or TRACE_MARKERS), make it converts pt-regs to bpf_ctx->arg1, > arg2.., then top models and architectures can be separated by bpf. > > BPF bytecode is cross-platform, but what we can get by using bpf+kprobes > is a 'regs->rdx' kind of information, such information is both > architecture and kernel version related. for kprobes in the middle of the function, kernel cannot convert pt_regs into argN. Placement was decided by compiler and can only be found in debug info. I think bpf+kprobe will be using it when it is available. When there is no debug info, kprobes will be limited to function entry and mapping of regs/stack into argN can be done by user space depending on architecture. So user tracing scripts in some higher level language can be kernel/arch independent when 'perf probe+bpf' is loading them on the fly on the given machine. > We hope to establish some models for describing kernel procedures such > as IO and network, which requires that it does not rely on architecture > and does not rely to a specific kernel version as much as possible. That's obviously a goal, but it requires a new approach to tracepoints. I think a lot of great ideas were discussed in this thread, so I'm hopeful that we'll come up with solution that will satisfy even strictest Peter's requirements :)
WARNING: multiple messages have this Message-ID (diff)
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> To: Hekuang <hekuang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> Cc: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>, Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Namhyung Kim <namhyung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Arnaldo Carvalho de Melo <acme-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, Jiri Olsa <jolsa-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Masami Hiramatsu <masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org>, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Network Development <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>, wangnan0-hv44wF8Li93QT0dZR+AlfA@public.gmane.org Subject: Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Date: Sat, 14 Feb 2015 18:02:41 -0500 [thread overview] Message-ID: <CAMEtUuy42YvUVpecTcJpmqgmRQ=fpR3C+pTD0ij+R_5COYg6zQ@mail.gmail.com> (raw) On Wed, Feb 11, 2015 at 11:58 PM, Hekuang <hekuang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote: > >>> eBPF is very flexible, which means it is bound to have someone use it >>> in a way you never dreamed of, and that will be what bites you in the >>> end (pun intended). >> >> understood :) >> let's start slow then with bpf+syscall and bpf+kprobe only. > > > I think BPF + system calls/kprobes can meet our use case > (https://lkml.org/lkml/2015/2/6/44), but there're some issues to be > improved. > > I suggest that you can improve bpf+kprobes when attached to function > headers(or TRACE_MARKERS), make it converts pt-regs to bpf_ctx->arg1, > arg2.., then top models and architectures can be separated by bpf. > > BPF bytecode is cross-platform, but what we can get by using bpf+kprobes > is a 'regs->rdx' kind of information, such information is both > architecture and kernel version related. for kprobes in the middle of the function, kernel cannot convert pt_regs into argN. Placement was decided by compiler and can only be found in debug info. I think bpf+kprobe will be using it when it is available. When there is no debug info, kprobes will be limited to function entry and mapping of regs/stack into argN can be done by user space depending on architecture. So user tracing scripts in some higher level language can be kernel/arch independent when 'perf probe+bpf' is loading them on the fly on the given machine. > We hope to establish some models for describing kernel procedures such > as IO and network, which requires that it does not rely on architecture > and does not rely to a specific kernel version as much as possible. That's obviously a goal, but it requires a new approach to tracepoints. I think a lot of great ideas were discussed in this thread, so I'm hopeful that we'll come up with solution that will satisfy even strictest Peter's requirements :)
next reply other threads:[~2015-02-14 23:03 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-14 23:02 Alexei Starovoitov [this message] 2015-02-14 23:02 ` [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Alexei Starovoitov -- strict thread matches above, loose matches on Subject: below -- 2015-02-23 18:55 Alexei Starovoitov 2015-02-23 18:55 ` Alexei Starovoitov 2015-02-14 22:54 Alexei Starovoitov 2015-02-14 22:54 ` Alexei Starovoitov 2015-02-14 22:48 Alexei Starovoitov 2015-02-14 22:48 ` Alexei Starovoitov 2015-02-11 6:33 Alexei Starovoitov 2015-02-11 6:33 ` Alexei Starovoitov 2015-02-11 12:51 ` Steven Rostedt 2015-02-11 12:51 ` Steven Rostedt 2015-02-11 3:04 Alexei Starovoitov 2015-02-11 4:31 ` Steven Rostedt 2015-02-11 4:31 ` Steven Rostedt 2015-02-11 0:22 Alexei Starovoitov 2015-02-11 0:50 ` Steven Rostedt 2015-02-11 0:50 ` Steven Rostedt 2015-02-11 9:33 ` Peter Zijlstra 2015-02-11 9:45 ` Peter Zijlstra 2015-02-11 9:45 ` Peter Zijlstra 2015-02-11 10:15 ` Peter Zijlstra 2015-02-11 10:15 ` Peter Zijlstra 2015-02-12 4:58 ` Hekuang 2015-02-12 4:58 ` Hekuang 2015-02-12 4:58 ` Hekuang 2015-02-16 11:26 ` He Kuang 2015-02-16 11:26 ` He Kuang 2015-02-10 19:53 Alexei Starovoitov 2015-02-10 21:53 ` Steven Rostedt 2015-02-10 21:53 ` Steven Rostedt 2015-02-11 10:28 ` Peter Zijlstra 2015-02-11 10:28 ` Peter Zijlstra 2015-02-10 6:10 Alexei Starovoitov 2015-02-10 6:10 ` Alexei Starovoitov 2015-02-10 13:05 ` Steven Rostedt 2015-02-10 13:05 ` Steven Rostedt 2015-02-10 5:51 Alexei Starovoitov 2015-02-10 5:51 ` Alexei Starovoitov 2015-02-10 12:27 ` Steven Rostedt 2015-02-10 3:45 [PATCH v3 linux-trace 0/8] tracing: attach eBPF programs to tracepoints/syscalls/kprobe Alexei Starovoitov 2015-02-10 3:45 ` [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Alexei Starovoitov 2015-02-10 3:45 ` Alexei Starovoitov 2015-02-10 4:46 ` Steven Rostedt 2015-02-10 4:46 ` Steven Rostedt 2015-02-10 5:13 ` Steven Rostedt 2015-02-10 5:13 ` Steven Rostedt
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='CAMEtUuy42YvUVpecTcJpmqgmRQ=fpR3C+pTD0ij+R_5COYg6zQ@mail.gmail.com' \ --to=ast@plumgrid.com \ --cc=acme@infradead.org \ --cc=ebiederm@xmission.com \ --cc=hekuang@huawei.com \ --cc=jolsa@redhat.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=masami.hiramatsu.pt@hitachi.com \ --cc=mingo@kernel.org \ --cc=namhyung@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=peterz@infradead.org \ --cc=rostedt@goodmis.org \ --cc=torvalds@linux-foundation.org \ --cc=wangnan0@huawei.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: linkBe 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.