lkml.org 
[lkml]   [2019]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v10 perf, bpf-next 1/9] perf, bpf: Introduce PERF_RECORD_KSYMBOL
Date


> 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?

Thanks again!
Song



\
 
 \ /
  Last update: 2019-01-17 15:50    [W:0.104 / U:25.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site