Re: [PATCH] perf bpf-filter: Support multiple events properly

[Namhyung Kim <namhyung@kernel.org>]

On Mon, Aug 05, 2024 at 02:12:01PM -0700, Namhyung Kim wrote:
> On Mon, Aug 05, 2024 at 04:31:34PM -0300, Arnaldo Carvalho de Melo wrote:
> > On Mon, Aug 05, 2024 at 11:56:56AM -0700, Namhyung Kim wrote:
> > > On Mon, Aug 05, 2024 at 12:03:14PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > On Fri, Aug 02, 2024 at 10:37:52AM -0700, Namhyung Kim wrote:
> > > > > + * The BPF program returns 1 to accept the sample or 0 to drop it.
> > > > > + * The 'dropped' map is to keep how many samples it dropped by the filter and
> > > > > + * it will be reported as lost samples.
> > > > 
> > > > I think there is value in reporting how many were filtered out, I'm just
> > > > unsure about reporting it as "lost" samples, as lost has another
> > > > semantic associated, i.e. ring buffer was full or couldn't process it
> > > > for some other resource starvation issue, no?
> > > 
> > > Then we need a way to save the information.  It could be a new record
> > > type (PERF_RECORD_DROPPED_SAMPLES), a new misc flag in the lost samples
> > 
> > I guess "PERF_RECORD_FILTERED_SAMPLES" would be better, more precise,
> > wdyt?
> > 
> > > record or a header field.  I prefer the misc flag.
> > 
> > I think we can have both filtered and lost samples, so I would prefer
> > the new record type.
> 
> I think we can have two LOST_SAMPLES records then - one with the new
> misc flag for BPF and the other (without the flag) for the usual lost
> samples.  This would require minimal changes IMHO.

I've realized that I already added PERF_RECORD_MISC_LOST_SAMPLES_BPF in
the commit 27c6f2455b29f ("perf record: Record dropped sample count"). :)

I'll add that to the event stats.

Thanks,
Namhyung