From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Song Liu <songliubraving@fb.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Netdev <netdev@vger.kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <Kernel-team@fb.com>, David Ahern <dsahern@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v10 perf, bpf-next 1/9] perf, bpf: Introduce PERF_RECORD_KSYMBOL
Date: Thu, 17 Jan 2019 11:58:54 -0300 [thread overview]
Message-ID: <20190117145854.GD5823@kernel.org> (raw)
In-Reply-To: <A411D89E-0B62-4DE7-9D70-CD57672FD20A@fb.com>
Em Thu, Jan 17, 2019 at 02:49:10PM +0000, Song Liu escreveu:
>
>
> > On Jan 17, 2019, at 4:56 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Wed, Jan 16, 2019 at 08:29:23AM -0800, Song Liu wrote:
> >> For better performance analysis of dynamically JITed and loaded kernel
> >> functions, such as BPF programs, this patch introduces
> >> PERF_RECORD_KSYMBOL, a new perf_event_type that exposes kernel symbol
> >> register/unregister information to user space.
> >>
> >> The following data structure is used for PERF_RECORD_KSYMBOL.
> >>
> >> /*
> >> * struct {
> >> * struct perf_event_header header;
> >> * u64 addr;
> >> * u32 len;
> >> * u16 ksym_type;
> >> * u16 flags;
> >> * char name[];
> >> * struct sample_id sample_id;
> >> * };
> >> */
> >
> > So I've cobbled together the attached patches to see how it would work
> > out..
> >
> > I didn't convert ftrace trampolines; because ftrace code has this
> > uncanny ability to make my head hurt. But I don't think it should be
> > hard, once one figures out the right structure to stick that
> > kallsym_node thing in (ftrace_ops ?!).
> >
> > It is compiled only, so no testing what so ever (also, no changelogs).
> >
> > I didn't wire up the KSYM_TYPE thing; I'm wondering if we really need
> > that, OTOH it really doesn't hurt having it either.
> >
> > One weird thing I noticed, wth does bpf_prog_kallsyms_add() check
> > CAP_ADMIN ?! Surely even a non-priv JIT'ed program generates symbols,
> > why hide those?
> >
> > Anyway; with the one nit about the get_names() thing sorted:
> >
> > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> >
> > (thanks for sticking with this)
> > <peterz-latch-next.patch><peterz-kallsym.patch><peterz-kallsym-bpf.patch>
>
> Aha, now I get the point on perf_event_ksymbol(). Yeah this approach is
> definitely better.
>
> While I run more tests with these patches, could we get current in
> perf/core? This will enable the development of user space tools like
> bcc.
>
> Also, I current base this set on bpf-next tree, as tip/perf/core is
> 4 week old. Shall I rebase the set on Linus' tree? Or shall I wait for
> tip/perf/core?
So, can you post one last set, this time with PeterZ's Acked-by,
assuming you're sorting out the get_names() thing, and I can try merging
this into my perf/core branch, then pushing it out to Ingo, my perf/core
starts from tip/perf/urgent, so should be new enough.
I'd then right after testing it send a pull request to Ingo, synching
everything.
- Arnaldo
next prev parent reply other threads:[~2019-01-17 14:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-16 16:29 [PATCH v10 perf, bpf-next 0/9] reveal invisible bpf programs Song Liu
2019-01-16 16:29 ` [PATCH v10 perf, bpf-next 1/9] perf, bpf: Introduce PERF_RECORD_KSYMBOL Song Liu
2019-01-17 12:48 ` Peter Zijlstra
2019-01-17 12:56 ` Peter Zijlstra
2019-01-17 14:49 ` Song Liu
2019-01-17 14:58 ` Arnaldo Carvalho de Melo [this message]
2019-01-17 15:02 ` Song Liu
2019-01-18 8:38 ` Peter Zijlstra
2019-01-18 8:41 ` Peter Zijlstra
2019-01-16 16:29 ` [PATCH v10 perf, bpf-next 2/9] sync tools/include/uapi/linux/perf_event.h Song Liu
2019-01-16 16:29 ` [PATCH v10 perf, bpf-next 3/9] perf, bpf: introduce PERF_RECORD_BPF_EVENT Song Liu
2019-01-17 13:09 ` Peter Zijlstra
2019-01-17 13:49 ` Song Liu
2019-01-16 16:29 ` [PATCH v10 perf, bpf-next 4/9] sync tools/include/uapi/linux/perf_event.h Song Liu
2019-01-16 16:29 ` [PATCH v10 perf, bpf-next 5/9] perf util: handle PERF_RECORD_KSYMBOL Song Liu
2019-01-16 16:29 ` [PATCH v10 perf, bpf-next 6/9] perf util: handle PERF_RECORD_BPF_EVENT Song Liu
2019-01-16 16:29 ` [PATCH v10 perf, bpf-next 7/9] perf tools: synthesize PERF_RECORD_* for loaded BPF programs Song Liu
2019-01-16 16:29 ` [PATCH v10 perf, bpf-next 8/9] perf top: Synthesize BPF events for pre-existing " Song Liu
2019-01-16 16:29 ` [PATCH v10 perf, bpf-next 9/9] bpf: add module name [bpf] to ksymbols for bpf programs Song Liu
2019-01-17 13:10 ` 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=20190117145854.GD5823@kernel.org \
--to=acme@kernel.org \
--cc=Kernel-team@fb.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=dsahern@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=songliubraving@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).