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

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