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
