netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Song Liu <liu.song.a23@gmail.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	acme@kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Alexei Starovoitov <ast@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Networking <netdev@vger.kernel.org>,
	kernel-team@fb.com
Subject: Re: [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog load/unload
Date: Wed, 17 Oct 2018 08:09:40 -0700	[thread overview]
Message-ID: <9b9f5977-df19-3f76-afd4-7e9419bd7752@gmail.com> (raw)
In-Reply-To: <CAPhsuW7zZE51ibma__y8SDVUU_YQMjGyHRhYDhBsuJF_b89h6g@mail.gmail.com>

On 10/16/18 11:43 PM, Song Liu wrote:
> I agree that processing events while recording has significant overhead.
> In this case, perf user space need to know details about the the jited BPF
> program. It is impossible to pass all these details to user space through
> the relatively stable ring_buffer API. Therefore, some processing of the
> data is necessary (get bpf prog_id from ring buffer, and then fetch program
> details via BPF_OBJ_GET_INFO_BY_FD.
> 
> I have some idea on processing important data with relatively low overhead.
> Let me try implement it.
> 

As I understand it, you want this series:

 kernel: add event to perf buffer on bpf prog load

 userspace: perf reads the event and grabs information about the program
from the fd

Is that correct?

Userpsace is not awakened immediately when an event is added the the
ring. It is awakened once the number of events crosses a watermark. That
means there is an unknown - and potentially long - time window where the
program can be unloaded before perf reads the event.

So no matter what you do expecting perf record to be able to process the
event quickly is an unreasonable expectation.

  parent reply	other threads:[~2018-10-17 23:05 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-19 22:39 [PATCH bpf-next 0/3] perf, bpf: reveal invisible bpf programs Alexei Starovoitov
2018-09-19 22:39 ` [PATCH bpf-next 1/3] perf/core: introduce perf_event_mmap_bpf_prog Alexei Starovoitov
2018-09-19 23:30   ` Song Liu
2018-09-20  0:53     ` Alexei Starovoitov
2018-09-19 22:39 ` [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog load/unload Alexei Starovoitov
2018-09-19 23:44   ` Song Liu
2018-09-20  0:59     ` Alexei Starovoitov
2018-09-20  5:48       ` Song Liu
2018-09-20  8:44   ` Peter Zijlstra
2018-09-20 13:25     ` Arnaldo Carvalho de Melo
2018-09-20 13:56       ` Peter Zijlstra
2018-09-21  3:14         ` Alexei Starovoitov
2018-09-21 12:25           ` Arnaldo Carvalho de Melo
2018-09-21 13:55             ` Peter Zijlstra
2018-09-21 13:59             ` Peter Zijlstra
2018-09-21 22:13             ` Alexei Starovoitov
2018-10-15 23:33               ` Song Liu
2018-10-16 23:43                 ` David Ahern
2018-10-17  6:43                   ` Song Liu
2018-10-17 12:11                     ` Arnaldo Carvalho de Melo
2018-10-17 12:50                       ` Arnaldo Carvalho de Melo
2018-10-17 16:06                         ` Song Liu
2018-11-02  1:08                       ` Song Liu
2018-10-17 15:09                     ` David Ahern [this message]
2018-10-17 16:18                       ` Song Liu
2018-10-17 16:36                       ` Alexei Starovoitov
2018-10-17 18:53                         ` Arnaldo Carvalho de Melo
2018-10-17 19:08                           ` Alexei Starovoitov
2018-10-17 21:31                             ` Arnaldo Carvalho de Melo
2018-10-17 22:01                               ` Alexei Starovoitov
2018-09-20 13:36     ` Peter Zijlstra
2018-09-19 22:39 ` [PATCH perf 3/3] tools/perf: recognize and process RECORD_MMAP events for bpf progs Alexei Starovoitov
2018-09-20 13:36   ` Arnaldo Carvalho de Melo
2018-09-20 14:05     ` Arnaldo Carvalho de Melo
2018-09-21 22:57   ` Song Liu

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=9b9f5977-df19-3f76-afd4-7e9419bd7752@gmail.com \
    --to=dsahern@gmail.com \
    --cc=acme@kernel.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kernel-team@fb.com \
    --cc=liu.song.a23@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    /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).