Re: [PATCH v6 perf, bpf-next 3/7] perf, bpf: introduce PERF_RECORD_BPF_EVENT

[Alexei Starovoitov <ast@fb.com>]

On 1/9/19 11:21 AM, Song Liu wrote:
> For better performance analysis of BPF programs, this patch introduces
> PERF_RECORD_BPF_EVENT, a new perf_event_type that exposes BPF program
> load/unload information to user space.
> 
> Each BPF program may contain up to BPF_MAX_SUBPROGS (256) sub programs.
> The following example shows kernel symbols for a BPF program with 7
> sub programs:
> 
>      ffffffffa0257cf9 t bpf_prog_b07ccb89267cf242_F
>      ffffffffa02592e1 t bpf_prog_2dcecc18072623fc_F
>      ffffffffa025b0e9 t bpf_prog_bb7a405ebaec5d5c_F
>      ffffffffa025dd2c t bpf_prog_a7540d4a39ec1fc7_F
>      ffffffffa025fcca t bpf_prog_05762d4ade0e3737_F
>      ffffffffa026108f t bpf_prog_db4bd11e35df90d4_F
>      ffffffffa0263f00 t bpf_prog_89d64e4abf0f0126_F
>      ffffffffa0257cf9 t bpf_prog_ae31629322c4b018__dummy_tracepoi
> 
> When a bpf program is loaded, PERF_RECORD_KSYMBOL is generated for
> each of these sub programs. Therefore, PERF_RECORD_BPF_EVENT is not
> needed for simple profiling.
> 
> For annotation, user space need to listen to PERF_RECORD_BPF_EVENT
> and gather more information about these (sub) programs via sys_bpf.
> 
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
>   include/linux/filter.h          |   7 ++
>   include/linux/perf_event.h      |   6 ++
>   include/uapi/linux/perf_event.h |  29 +++++++-
>   kernel/bpf/core.c               |   2 +-
>   kernel/bpf/syscall.c            |   2 +
>   kernel/events/core.c            | 120 ++++++++++++++++++++++++++++++++
>   6 files changed, 164 insertions(+), 2 deletions(-)

Acked-by: Alexei Starovoitov <ast@kernel.org>

The bpf bits are small comparing to perf bits, so it's probably
better to get the whole thing via tip tree in one go.
Splitting perf patches into perf tree also seems unnecessary.

Peter, Arnaldo, thoughts?