All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jack Henschel <jackdev@mailbox.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Andi Kleen <ak@linux.intel.com>,
	Taeung Song <treeze.taeung@gmail.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf parser: Improve error message for PMU address filters
Date: Thu, 19 Oct 2017 16:57:30 -0300	[thread overview]
Message-ID: <20171019195730.GB4059@kernel.org> (raw)
In-Reply-To: <ed218afa-f68e-205a-4d38-879615259320@mailbox.org>

Em Thu, Oct 19, 2017 at 09:37:13PM +0200, Jack Henschel escreveu:
> On 09/05/2017 11:08 AM, Jack Henschel wrote:
> > This patch improves the error message of the perf events parser
> > when the PMU hardware does not support address filters.
> > 
> > Previously, the perf returned the following error:
> >> --filter option should follow a -e tracepoint or HW tracer option
> > This implies there is some syntax error present in the command line,
> > which is not true. Rather, notify the user that the CPU does not have
> > support for this feature.
> > 
> > For example, Intel chips based on the Broadwell micro-archticture have
> > the Intel PT PMU, but do not support address filtering.
> > 
> > Signed-off-by: Jack Henschel <jackdev@mailbox.org>
> > ---
> >  tools/perf/util/parse-events.c | 20 ++++++++++----------
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> > index f44aeba51d1f..672b6d9423e9 100644
> > --- a/tools/perf/util/parse-events.c
> > +++ b/tools/perf/util/parse-events.c
> > @@ -1833,8 +1833,11 @@ static int set_filter(struct perf_evsel *evsel, const void *arg)
> >  	int nr_addr_filters = 0;
> >  	struct perf_pmu *pmu = NULL;
> >  
> > -	if (evsel == NULL)
> > -		goto err;
> > +	if (evsel == NULL) {
> > +		fprintf(stderr,
> > +			"--filter option should follow a -e tracepoint or HW tracer option\n");
> > +		return -1;
> > +	}
> >  
> >  	if (evsel->attr.type == PERF_TYPE_TRACEPOINT) {
> >  		if (perf_evsel__append_tp_filter(evsel, str) < 0) {
> > @@ -1856,8 +1859,11 @@ static int set_filter(struct perf_evsel *evsel, const void *arg)
> >  		perf_pmu__scan_file(pmu, "nr_addr_filters",
> >  				    "%d", &nr_addr_filters);
> >  
> > -	if (!nr_addr_filters)
> > -		goto err;
> > +	if (!nr_addr_filters) {
> > +		fprintf(stderr,
> > +			"This CPU does not support address filtering\n");
> > +		return -1;
> > +	}
> >  
> >  	if (perf_evsel__append_addr_filter(evsel, str) < 0) {
> >  		fprintf(stderr,
> > @@ -1866,12 +1872,6 @@ static int set_filter(struct perf_evsel *evsel, const void *arg)
> >  	}
> >  
> >  	return 0;
> > -
> > -err:
> > -	fprintf(stderr,
> > -		"--filter option should follow a -e tracepoint or HW tracer option\n");
> > -
> > -	return -1;
> >  }
> >  
> >  int parse_filter(const struct option *opt, const char *str,
> > 
> 
> Is there any interest in this patch? Did it get lost?
 
> > For example, Intel chips based on the Broadwell micro-archticture have
> > the Intel PT PMU, but do not support address filtering.

Can you provide this example with the tool output before and after? I
happen to have a Broadwell machine as my current notebook and would just
use this to test your patch.

And generally before/after command lines + output is good to quickly
show, in more concrete terms what the problem is and how it gets fixed.

- Arnaldo

  reply	other threads:[~2017-10-19 19:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-05  9:08 [PATCH] perf parser: Improve error message for PMU address filters Jack Henschel
2017-10-19 19:37 ` Jack Henschel
2017-10-19 19:57   ` Arnaldo Carvalho de Melo [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-07-04  9:54 Jack Henschel
2018-07-04 10:24 ` Jiri Olsa

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=20171019195730.GB4059@kernel.org \
    --to=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jackdev@mailbox.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=treeze.taeung@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.