Re: [RFC perf,bpf 5/5] perf util: generate bpf_prog_info_event for short living bpf programs

From: Alexei Starovoitov <ast@fb.com>
To: David Ahern <dsahern@gmail.com>, David Miller <davem@davemloft.net>
Cc: Song Liu <songliubraving@fb.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>,
	"ast@kernel.org" <ast@kernel.org>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"acme@kernel.org" <acme@kernel.org>
Subject: Re: [RFC perf,bpf 5/5] perf util: generate bpf_prog_info_event for short living bpf programs
Date: Wed, 7 Nov 2018 01:09:28 +0000	[thread overview]
Message-ID: <edda462f-a32c-bc25-94c8-8d06a47bd480@fb.com> (raw)
In-Reply-To: <7d0b100b-a64b-0d30-8ec0-2689ef44423d@gmail.com>

On 11/6/18 4:44 PM, David Ahern wrote:
> 
> So one use case is profiling bpf programs. I was also considering the
> auditing discussion from some weeks ago which I thought the events are
> also targeting.

yes. there should be separate mode for 're: audit discussion' where
only bpf events are collected. This patch set doesn't add that to
perf user space side.
The kernel side is common though. It can be used for bpf load/unload
only and for different use case in this set. Which is making
bpf program appear in normal 'perf report'.
Please see link in cover letter.
We decided to abandon my old approach in favor of this one,
but the end result is the same.
 From 0.81% cpu of some magic 0x00007fffa001a660
into 18.13% of bpf_prog_1accc788e7f04c38_balancer_ingres

> As for the overhead, I did not see a separate thread getting spun off
> for the bpf events, so the events are processed inline for this RFC set.

argh. you're right. we have to fix that.