From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Ahern <dsahern@gmail.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
Message-ID: <9b9f5977-df19-3f76-afd4-7e9419bd7752@gmail.com>
References: <20180919223935.999270-1-ast@kernel.org>
 <20180919223935.999270-3-ast@kernel.org>
 <20180920084424.GN24124@hirez.programming.kicks-ass.net>
 <20180920132545.GA19861@kernel.org>
 <20180920135651.GW24124@hirez.programming.kicks-ass.net>
 <20180921031444.fyem2ah6emimv24m@ast-mbp> <20180921122500.GA17312@kernel.org>
 <20180921221343.g52n7c4edisvice3@ast-mbp>
 <CAPhsuW7BO3gaaTPEyn2XdFTb+y5JBxU0oocJvMak=4jGHTJTqw@mail.gmail.com>
 <1593d595-58ef-22b3-d721-859453425e26@gmail.com>
 <CAPhsuW7zZE51ibma__y8SDVUU_YQMjGyHRhYDhBsuJF_b89h6g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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
To: Song Liu <liu.song.a23@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pg1-f196.google.com ([209.85.215.196]:40746 "EHLO
        mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1727182AbeJQXFv (ORCPT
        <rfc822;netdev@vger.kernel.org>); Wed, 17 Oct 2018 19:05:51 -0400
Received: by mail-pg1-f196.google.com with SMTP id n31-v6so12679506pgm.7
        for <netdev@vger.kernel.org>; Wed, 17 Oct 2018 08:09:44 -0700 (PDT)
In-Reply-To: <CAPhsuW7zZE51ibma__y8SDVUU_YQMjGyHRhYDhBsuJF_b89h6g@mail.gmail.com>
Content-Language: en-US
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

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.