From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [RFC perf,bpf 5/5] perf util: generate bpf_prog_info_event for short living bpf programs Date: Tue, 6 Nov 2018 17:44:13 -0700 Message-ID: <7d0b100b-a64b-0d30-8ec0-2689ef44423d@gmail.com> References: <6C5A9FBD-F50D-444C-9038-E9557EC850D2@fb.com> <27fc8327-3390-ba5a-6063-89c9e7165e7b@fb.com> <20181106.153647.1701013551426767213.davem@davemloft.net> <39fe6abc-5c3e-bac3-0c0b-cf68bea23ab0@fb.com> <0a05a14c-3a79-e894-ae48-cbe1df4feb91@gmail.com> <82745121-339e-2751-c9db-d1fca02d0b33@fb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Song Liu , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Kernel Team , "ast@kernel.org" , "daniel@iogearbox.net" , "peterz@infradead.org" , "acme@kernel.org" To: Alexei Starovoitov , David Miller Return-path: In-Reply-To: <82745121-339e-2751-c9db-d1fca02d0b33@fb.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 11/6/18 5:26 PM, Alexei Starovoitov wrote: > On 11/6/18 4:23 PM, David Ahern wrote: >> On 11/6/18 5:13 PM, Alexei Starovoitov wrote: >>> On 11/6/18 3:36 PM, David Miller wrote: >>>> From: Alexei Starovoitov >>>> Date: Tue, 6 Nov 2018 23:29:07 +0000 >>>> >>>>> I think concerns with perf overhead from collecting bpf events >>>>> are unfounded. >>>>> I would prefer for this flag to be on by default. >>>> >>>> I will sit in userspace looping over bpf load/unload and see how the >>>> person trying to monitor something else with perf feels about that. >>>> >>>> Really, it is inappropriate to turn this on by default, I completely >>>> agree with David Ahern. >>>> >>>> It's hard enough, _AS IS_, for me to fight back all of the bloat that >>>> is in perf right now and get it back to being able to handle simple >>>> full workloads without dropping events.. >>> >>> It's a separate perf thread and separate event with its own epoll. >>> I don't see how it can affect main event collection. >>> Let's put it this way. If it does affect somehow, then yes, >>> it should not be on. If it is not, there is no downside to keep it on. >>> Typical user expects to type 'perf record' and see everything that >>> is happening on the system. Right now short lived bpf programs >>> will not be seen. How user suppose to even know when to use the flag? >> >> The default is profiling where perf record collects task events and >> periodic samples. So for the default record/report, the bpf load / >> unload events are not relevant. > > Exactly the opposite. > It's for default 'perf record' collection of periodic samples. > It can be off for -e collection. That's easy. > 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. 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.