From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [RFC perf,bpf 1/5] perf, bpf: Introduce PERF_RECORD_BPF_EVENT Date: Thu, 8 Nov 2018 11:26:12 -0700 Message-ID: References: <20181106205246.567448-1-songliubraving@fb.com> <20181106205246.567448-2-songliubraving@fb.com> <20181107084057.GG9781@hirez.programming.kicks-ass.net> <31067290-4B66-4AA1-8027-607397BC0264@fb.com> <20181108150028.GU9761@hirez.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Netdev , lkml , Kernel Team , "ast@kernel.org" , "daniel@iogearbox.net" , "acme@kernel.org" To: Song Liu , Peter Zijlstra Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 11/8/18 11:04 AM, Song Liu wrote: > On the other hand, processing BPF load/unload events synchronously should > not introduce too much overhead for meaningful use cases. If many BPF progs > are being loaded/unloaded within short period of time, it is not the steady > state that profiling works care about. but, profiling is not the only use case, and perf-record is common with those other use cases. I think that answers why your RFC set does not fork a thread for the bpf events. You are focused on profiling and for already loaded programs or for a small number of programs loaded by a specific workload started by perf.