Skip to contentSkip to conversation

perf hists browser: Take the --comm, --dsos, etc filters into account

tip:perf/urgent tip-bot for Arnaldo Carvalho de Melo 1 participant 1 message Jul 15, 2015 perf events

lore
Share & tools
lore
#0 lore raw
Commit-ID:  9c0fa8dd3d58de8b688fda758eea1719949c7f0a
Gitweb:     http://git.kernel.org/tip/9c0fa8dd3d58de8b688fda758eea1719949c7f0a
Author:     Arnaldo Carvalho de Melo <[email protected]>
AuthorDate: Mon, 13 Jul 2015 08:26:35 -0300
Committer:  Arnaldo Carvalho de Melo <[email protected]>
CommitDate: Mon, 13 Jul 2015 16:06:09 -0300

perf hists browser: Take the --comm, --dsos, etc filters into account

At some point:

commit 2c86c7ca7606
Author: Namhyung Kim <[email protected]>
Date: Mon Mar 17 18:18:54 2014 -0300

    perf report: Merge al->filtered with hist_entry->filtered

We stopped dropping samples for things filtered via the --comms, --dsos, --symbols, etc, i.e. things marked as filtered in the symbol resolution routines (thread__find_addr_map(), perf_event__preprocess_sample(), etc).

But then, in:

commit 268397cb2a47
Author: Namhyung Kim <[email protected]>
Date: Tue Apr 22 14:49:31 2014 +0900

perf top/tui: Update nr_entries properly after a filter is applied

We don't take into account entries that were filtered in perf_event__preprocess_sample() and friends, which leads to inconsistency in the browser seek routines, that expects the number of hist_entry->filtered entries to match what it thinks is the number of unfiltered, browsable entries.

So, for instance, when we do:

  perf top --symbols ___non_existent_symbol___

the hist_browser__nr_entries() routine thinks there are no filters in place, uses the hists->nr_entries but all entries are filtered, leading to a segfault.

Tested with:

   perf top --symbols malloc,free --percentage=relative

Freezing, by pressing 'f', at any time and doing the math on the percentages ends up with 100%, ditto for:

   perf top --dsos libpthread-2.20.so,libxul.so --percentage=relative

Both were segfaulting, all fixed now.

More work needed to do away with checking if filters are in place, we should just use the nr_non_filtered_samples counter, no need to conditionally use it or hists.nr_filter, as what the browser does is just show unfiltered stuff. An audit of how it is being accounted is needed, this is the minimal fix.

Fixes 268397cb2a47 ("perf top/tui: Update nr_entries properly after a filter is applied")
Cc Adrian Hunter <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Ahern <[email protected]>
Cc Frederic Weisbecker <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Namhyung Kim <[email protected]>
Cc Stephane Eranian <[email protected]>
---
 tools/perf/ui/browsers/hists.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/ui/browsers/hists.c +1 -1
index 7629bef..fa67613 100644
@@ -48,7 +48,7 @@ static struct rb_node *hists__filter_entries(struct rb_node *nd,
 
 static bool hist_browser__has_filter(struct hist_browser *hb)
 {
-	return hists__has_filter(hb->hists) || hb->min_pcnt;
+	return hists__has_filter(hb->hists) || hb->min_pcnt || symbol_conf.has_filter;
 }
 
 static int hist_browser__get_folding(struct hist_browser *browser)