On Tue, Aug 20, 2024 at 3:50 PM Namhyung Kim <namhyung@xxxxxxxxxx> wrote: > > On Tue, Aug 20, 2024 at 1:51 PM Arnaldo Carvalho de Melo > <acme@xxxxxxxxxx> wrote: > > > > On Tue, Aug 20, 2024 at 08:45:03AM -0700, Namhyung Kim wrote: > > > +++ b/tools/perf/builtin-report.c > > > @@ -795,8 +795,13 @@ static int count_lost_samples_event(const struct perf_tool *tool, > > > > > > evsel = evlist__id2evsel(rep->session->evlist, sample->id); > > > if (evsel) { > > > - hists__inc_nr_lost_samples(evsel__hists(evsel), > > > - event->lost_samples.lost); > > > + struct hists *hists = evsel__hists(evsel); > > > + u32 count = event->lost_samples.lost; > > > + > > > + if (event->header.misc & PERF_RECORD_MISC_LOST_SAMPLES_BPF) > > > + hists__inc_nr_dropped_samples(hists, count); > > > > So this is inconsistent, we call it sometimes "lost", sometines > > "dropped", I think we should make it consistent and call it "dropped", > > because its not like it was "lost" because we didn't have the required > > resources, memory, ring buffer being full, etc, i.e. the semantic > > associated with PERF_RECORD_LOST. > > > > I.e. LOST is non intentional, not expected, DROPPED is the result of the > > user _asking_ for something to be trown away, to be filtered, its > > expected behaviour, there is value in differentiating one from the > > other. > > Yep, that's because it's piggybacking on PERF_RECORD_LOST_SAMPLES. > Do you want me to add a new (user) record format for dropped samples? Ok, I have a related issue with AMD IBS. I'll start a new discussion in a different thread. I think you can take patch 1 and 3 in this series as they are not controversial, right? Thanks, Namhyung