public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, vince@deater.net,
	eranian@google.com, Arnaldo Carvalho de Melo <acme@infradead.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>
Subject: Re: [PATCH v0 3/5] perf: Introduce instruction trace filtering
Date: Fri, 11 Dec 2015 15:52:53 +0100	[thread overview]
Message-ID: <20151211145253.GR6356@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20151211142335.GC20666@leverpostej>

On Fri, Dec 11, 2015 at 02:23:36PM +0000, Mark Rutland wrote:
> On Fri, Dec 11, 2015 at 03:02:01PM +0100, Peter Zijlstra wrote:
> > On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> > 
> > > The pmu driver interface basically adds an extra callback to the
> > > pmu driver structure, which validates the filter configuration proposed
> > > by the user against what the hardware is actually capable of doing
> > > and translates it into something that pmu::start can program into
> > > hardware.
> > 
> > > @@ -388,12 +393,38 @@ struct pmu {
> > >  	void (*free_aux)		(void *aux); /* optional */
> > >  
> > >  	/*
> > > +	 * Validate instruction tracing filters: make sure hw supports the
> > > +	 * requested configuration and number of filters.
> > > +	 *
> > > +	 * Configure instruction tracing filters: translate hw-agnostic filter
> > > +	 * into hardware configuration in event::hw::itrace_filters
> > > +	 */
> > > +	int (*itrace_filter_setup)	(struct perf_event *event); /* optional */
> > > +
> > > +	/*
> > >  	 * Filter events for PMU-specific reasons.
> > >  	 */
> > >  	int (*filter_match)		(struct perf_event *event); /* optional */
> > >  };
> > 
> > Any reason you cannot use pmu::filter_match ?
> 
> Maybe I've misunderstood your point, but the two seem quite different.
> 
> We introduced pmu::filter_match to apply a SW filter each time we
> installed events from a context. We use that on ARM to avoid programming
> big events into little cores and vice-versa.
> 
> As far as I can see, itrace_filter_setup is closer in operation to
> event_init. It can fail at configuration time (long before scheduling
> events to cores), and leaves the actual filtering to the HW.

Ah indeed. I got confused by the similarities in the signature and both
having filter in the name.

Alexander, maybe then add a filter parameter to validate to the
signature, otherwise you have to change the event state in order to
validate it which leaves you with an invalid configured event in case it
doesn't validate.

  reply	other threads:[~2015-12-11 14:52 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-11 13:36 [PATCH v0 0/5] perf: Introduce instruction trace filtering Alexander Shishkin
2015-12-11 13:36 ` [PATCH v0 1/5] perf: Move set_filter() from behind EVENT_TRACING Alexander Shishkin
2015-12-11 13:36 ` [PATCH v0 2/5] perf: Extend perf_event_aux() to optionally iterate through more events Alexander Shishkin
2015-12-11 13:36 ` [PATCH v0 3/5] perf: Introduce instruction trace filtering Alexander Shishkin
2015-12-11 14:02   ` Peter Zijlstra
2015-12-11 14:20     ` Alexander Shishkin
2015-12-11 14:23     ` Mark Rutland
2015-12-11 14:52       ` Peter Zijlstra [this message]
2015-12-11 15:12         ` Alexander Shishkin
2015-12-11 14:56   ` Peter Zijlstra
2015-12-11 15:14     ` Alexander Shishkin
2015-12-11 15:00   ` Peter Zijlstra
2015-12-11 15:17     ` Alexander Shishkin
2015-12-11 15:34       ` Peter Zijlstra
2015-12-11 16:06     ` Alexander Shishkin
2015-12-11 15:02   ` Peter Zijlstra
2015-12-11 15:20     ` Peter Zijlstra
2015-12-11 15:27     ` Alexander Shishkin
2015-12-11 15:33       ` Peter Zijlstra
2015-12-11 15:48         ` Alexander Shishkin
2015-12-11 16:01           ` Peter Zijlstra
2015-12-11 17:02             ` Peter Zijlstra
2015-12-11 15:09   ` Peter Zijlstra
2015-12-11 15:12   ` Peter Zijlstra
2015-12-11 15:28   ` Peter Zijlstra
2015-12-11 17:00     ` Peter Zijlstra
2015-12-11 17:13       ` Alexander Shishkin
2015-12-11 22:39         ` Peter Zijlstra
2015-12-11 16:59   ` Peter Zijlstra
2015-12-11 17:15     ` Alexander Shishkin
2015-12-11 18:11   ` Mathieu Poirier
2015-12-11 22:41     ` Peter Zijlstra
2015-12-11 13:36 ` [PATCH v0 4/5] perf/x86/intel/pt: IP filtering register/cpuid bits Alexander Shishkin
2015-12-11 13:36 ` [PATCH v0 5/5] perf/x86/intel/pt: Add support for instruction trace filtering in PT Alexander Shishkin
2015-12-11 18:06   ` Mathieu Poirier
2015-12-11 21:38 ` [PATCH v0 0/5] perf: Introduce instruction trace filtering Mathieu Poirier
2015-12-14  8:50   ` Alexander Shishkin
2015-12-15  0:25     ` Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151211145253.GR6356@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@infradead.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=mingo@redhat.com \
    --cc=vince@deater.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox