From: Namhyung Kim <namhyung@kernel.org>
To: pi3orama <pi3orama@163.com>
Cc: He Kuang <hekuang@huawei.com>,
Alexei Starovoitov <ast@plumgrid.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"masami.hiramatsu.pt@hitachi.com"
<masami.hiramatsu.pt@hitachi.com>,
"acme@kernel.org" <acme@kernel.org>,
"a.p.zijlstra@chello.nl" <a.p.zijlstra@chello.nl>,
"mingo@redhat.com" <mingo@redhat.com>,
"jolsa@kernel.org" <jolsa@kernel.org>,
"wangnan0@huawei.com" <wangnan0@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
Date: Mon, 13 Jul 2015 23:09:15 +0900 [thread overview]
Message-ID: <20150713140915.GD9917@danjae.kornet> (raw)
In-Reply-To: <4D441676-21A7-46EE-AAB0-EB529D408082@163.com>
On Mon, Jul 13, 2015 at 10:01:26PM +0800, pi3orama wrote:
>
>
> 发自我的 iPhone
>
> > 在 2015年7月13日,下午9:52,Namhyung Kim <namhyung@kernel.org> 写道:
> >
> > Hi,
> >
> >> On Mon, Jul 13, 2015 at 12:36:27PM +0800, He Kuang wrote:
> >> hi, Alexei
> >>
> >>> On 2015/7/11 6:10, Alexei Starovoitov wrote:
> >>>> On 7/10/15 3:03 AM, He Kuang wrote:
> >>>> There're scenarios that we need an eBPF program to record not only
> >>>> kprobe point args, but also the PMU counters, time latencies or the
> >>>> number of cache misses between two probe points and other information
> >>>> when the probe point is entered.
> >>>>
> >>>> This patch adds a new trace event to establish infrastruction for bpf to
> >>>> output data to perf. Userspace perf tools can detect and use this event
> >>>> as using the existing tracepoint events.
> >>>>
> >>>> New bpf trace event entry in debugfs:
> >>>>
> >>>> /sys/kernel/debug/tracing/events/bpf/bpf_output_data
> >>>>
> >>>> Userspace perf tools detect the new tracepoint event as:
> >>>>
> >>>> bpf:bpf_output_data [Tracepoint event]
> >>>
> >>> Nice! This approach looks cleanest so far.
> >>>
> >>>> +TRACE_EVENT(bpf_output_data,
> >>>> +
> >>>> + TP_PROTO(u64 *src, int len),
> >>>> +
> >>>> + TP_ARGS(src, len),
> >>>> +
> >>>> + TP_STRUCT__entry(
> >>>> + __dynamic_array(u64, buf, len)
> >>>> + ),
> >>>> +
> >>>> + TP_fast_assign(
> >>>> + memcpy(__get_dynamic_array(buf), src, len * sizeof(u64));
> >>>
> >>> may be make it 'u8' array? The extra multiply and...
> >>
> >> OK
> >>
> >> So the output of three u64 integers (e.g. 0x2060572485, 0x20667b0ff2,
> >> 0x623eb6d) will be this:
> >>
> >> dd 994 [000] 139.158180: bpf:bpf_output_data: 85 24 57 60 20 00 00 00
> >> f2 0f 7b 66 20 00 00 00 6d eb 23 06 00 00 00 00
> >>
> >> And users are not restricted to u64 type elements. I'll change that.
> >
> > While this general event format works well, I think it might be hard
> > to know which output came from which program when more than one bpf
> > programs used.
> >
> > I was thinking about providing custom event formats for each bpf
> > program (if needed). The event format definitions might be in a
> > specific directory or a bpf object itself. Then perf can read those
> > formats and print the output data according to the formats. Maybe we
> > need to add some dynamic event id to match format and data.
> >
>
> I think we can do it in perf side. Let BPF programs themselves
> encode format information into the array and make perf read and
> decode them. In kernel side simply support raw data should be
> enough, so we can make kernel code as simple as possible.
Yes, of course, I also meant that doing those work all in perf side. :)
Thanks,
Namhyung
next prev parent reply other threads:[~2015-07-13 14:11 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 10:03 [RFC PATCH v4 0/3] Make eBPF programs output " He Kuang
2015-07-10 10:03 ` [RFC PATCH v4 1/3] tracing/events: Fix wrong sample output by storing array length instead of size He Kuang
2015-07-17 14:32 ` Steven Rostedt
2015-07-17 17:24 ` Sara Rostedt
2015-07-17 18:13 ` Steven Rostedt
2015-07-23 19:36 ` Alex Bennée
2015-07-10 10:03 ` [RFC PATCH v4 2/3] tools lib traceevent: Add function to get dynamic arrays length He Kuang
2015-07-10 10:03 ` [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event He Kuang
2015-07-10 22:10 ` Alexei Starovoitov
2015-07-13 4:36 ` He Kuang
2015-07-13 13:52 ` Namhyung Kim
2015-07-13 14:01 ` pi3orama
2015-07-13 14:09 ` Namhyung Kim [this message]
2015-07-13 14:29 ` pi3orama
2015-07-14 1:43 ` Alexei Starovoitov
2015-07-14 11:54 ` He Kuang
2015-07-17 4:11 ` Alexei Starovoitov
2015-07-17 4:14 ` Wangnan (F)
2015-07-17 4:27 ` Alexei Starovoitov
2015-07-23 11:54 ` He Kuang
2015-07-23 20:49 ` llvm bpf debug info. " Alexei Starovoitov
2015-07-24 3:20 ` Alexei Starovoitov
2015-07-24 4:16 ` He Kuang
2015-07-25 10:04 ` He Kuang
2015-07-28 2:18 ` Alexei Starovoitov
2015-07-29 9:38 ` He Kuang
2015-07-29 17:13 ` Alexei Starovoitov
2015-07-29 20:00 ` pi3orama
2015-07-29 22:20 ` Alexei Starovoitov
2015-07-31 10:18 ` Wangnan (F)
2015-07-31 10:20 ` [LLVM PATCH] BPF: add FRAMEADDR support Wang Nan
2015-07-31 10:21 ` [LLVM CLANG PATCH] BPF: add __builtin_bpf_typeid() Wang Nan
2015-07-31 10:48 ` llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event pi3orama
2015-08-03 19:44 ` Alexei Starovoitov
2015-08-04 9:01 ` Cc llvmdev: " Wangnan (F)
2015-08-05 1:58 ` Wangnan (F)
2015-08-05 2:05 ` Wangnan (F)
2015-08-05 6:51 ` [LLVMdev] " Wangnan (F)
2015-08-05 7:11 ` Alexei Starovoitov
2015-08-05 8:28 ` Wangnan (F)
2015-08-06 3:22 ` [llvm-dev] " Alexei Starovoitov
2015-08-06 4:35 ` Wangnan (F)
2015-08-06 6:55 ` Alexei Starovoitov
2015-08-12 2:34 ` Wangnan (F)
2015-08-12 4:57 ` [llvm-dev] " Alexei Starovoitov
2015-08-12 5:28 ` Wangnan (F)
2015-08-12 13:15 ` Brenden Blanco
2015-08-13 6:24 ` Wangnan (F)
2015-08-05 8:59 ` [LLVMdev] Cc llvmdev: " He Kuang
2015-08-06 3:41 ` [llvm-dev] " Alexei Starovoitov
2015-08-06 4:31 ` Wangnan (F)
2015-08-06 6:50 ` Alexei Starovoitov
2015-07-13 8:29 ` Peter Zijlstra
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=20150713140915.GD9917@danjae.kornet \
--to=namhyung@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=ast@plumgrid.com \
--cc=hekuang@huawei.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=pi3orama@163.com \
--cc=rostedt@goodmis.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome