Re: [PATCH 2/9] perf tools: Count periods of filtered entries separately

[Arnaldo Carvalho de Melo <acme@ghostprotocols.net>]

Em Tue, Mar 18, 2014 at 01:19:07PM +0900, Namhyung Kim escreveu:
> On Tue, Mar 18, 2014 at 5:08 AM, Arnaldo Carvalho de Melo
> <acme@ghostprotocols.net> wrote:
> > Em Mon, Mar 10, 2014 at 04:43:53PM +0900, Namhyung Kim escreveu:
> >> @@ -749,9 +750,6 @@ int perf_event__preprocess_sample(const union perf_event *event,
> >>       if (thread == NULL)
> >>               return -1;
> >>
> >> -     if (thread__is_filtered(thread))
> >> -             goto out_filtered;
> >> -
> >
> > What was the intent of moving this test from here...
> >
> >>       dump_printf(" ... thread: %s:%d\n", thread__comm_str(thread), thread->tid);
> >>       /*
> >>        * Have we already created the kernel maps for this machine?
> >> @@ -766,6 +764,10 @@ int perf_event__preprocess_sample(const union perf_event *event,
> >>
> >>       thread__find_addr_map(thread, machine, cpumode, MAP__FUNCTION,
> >>                             sample->ip, al);
> >> +
> >> +     if (thread__is_filtered(thread))
> >> +             al->filtered |= (1 << HIST_FILTER__THREAD);
> >> +
> >
> > ... to here? At first I thought it was because thread__is_filtered()
> > would check something that thread__find_addr_map() was doing, but no,
> > its invariant, we can do it here or at the original site, so I'm keeping
> > it there, ok?
> 
> It's because thread__find_addr_map() clears al->filtered, so filtering
> with -d option won't work.  Maybe we can move initialization of the
> al->filtered upto this function.

So this is a separate patch with this explanation, I'll add it to the
series, thanks for the explanation!

- Arnaldo