Messages in this thread |  | | From | Alexei Starovoitov <> | | Subject | Re: [RFC perf,bpf 5/5] perf util: generate bpf_prog_info_event for short living bpf programs | | Date | Wed, 7 Nov 2018 00:26:16 +0000 |
| |
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 <ast@fb.com> >>> 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.
|  |