[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140318131831.GN31482@ghostprotocols.net>
Date: Tue, 18 Mar 2014 10:18:31 -0300
From: Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...nel.org>,
Paul Mackerras <paulus@...ba.org>,
Namhyung Kim <namhyung.kim@....com>,
LKML <linux-kernel@...r.kernel.org>,
Jiri Olsa <jolsa@...hat.com>, David Ahern <dsahern@...il.com>,
Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH 2/9] perf tools: Count periods of filtered entries
separately
Em Tue, Mar 18, 2014 at 10:15:18AM -0300, Arnaldo Carvalho de Melo escreveu:
> 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@...stprotocols.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!
Humm, it really needs to be folded into the patch that does all the
tests, as before we were just stopping the filters early and thus no
problem existed, its only now that we apply all the filters that we need
to be careful in knowing that thread__find_addr_map() is when
al->filtered gets initialized to zero, right?
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists