From: agustinv@codeaurora.org (Agustin Vega-Frias)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC V2 1/3] perf, tools: Support wildcards on pmu name in dynamic pmu events
Date: Mon, 05 Mar 2018 15:10:43 -0500 [thread overview]
Message-ID: <94ecc9b1337d15fe4634da56cb428738@codeaurora.org> (raw)
In-Reply-To: <20180305190937.GA31349@krava>
On 2018-03-05 14:09, Jiri Olsa wrote:
> On Mon, Mar 05, 2018 at 10:08:18AM -0500, Agustin Vega-Frias wrote:
>> On 2018-03-04 13:10, Jiri Olsa wrote:
>> > On Sun, Mar 04, 2018 at 09:12:45AM -0800, Andi Kleen wrote:
>> > > > > +#include <fnmatch.h>
>> > > > > #include <linux/compiler.h>
>> > > > > #include <linux/list.h>
>> > > > > #include <linux/types.h>
>> > > > > @@ -241,7 +242,7 @@ PE_NAME opt_event_config
>> > > > > if (!strncmp(name, "uncore_", 7) &&
>> > > > > strncmp($1, "uncore_", 7))
>> > > > > name += 7;
>> > > > > - if (!strncmp($1, name, strlen($1))) {
>> > > > > + if (!strncmp($1, name, strlen($1)) || !fnmatch($1, name, 0)) {
>> > > >
>> > > > could we now get rid of the strncmp in here and keep the
>> > > > glob matching only?
>> > >
>> > > That would break existing command lines. Not a good idea.
>> >
>> > I hoped that only you guys are using this and would rewrite your scripts
>> > ;-)
>> >
>> > I had no idea there's fnmatch func before.. too bad, ok
>> >
>> > jirka
>>
>> An option to keep backward compatibility and consistency would be
>> to wrap the pattern/string passed in *'s, that way we can just use
>> fnmatch and have all the examples Jiri brought up work the same.
>> With that in place we can actually also drop the explicit ignoring
>> of the uncore_ prefix since the globbing would take care of that.
>
> I don't mind the strcmp as such, I wanted to get rid of the wildcard
> matching without using '*' ... but as Andi said it's been out
> there and it's been a while, so let's keep it
>
> but if there's a way to make it simpler, let's go for it
>
> thanks,
> jirka
Sounds good. I have a new version ready (see sample output below).
But I wanted to ping about the other two patches before submitting.
Any feedback on those?
Thanks,
Agust?n
PS:
Sample output:
$ ./perf stat -a -e imc/umask=0x3,event=0x4/ --no-merge ls -l >
/dev/null
Performance counter stats for 'system wide':
2,613 uncore_imc_0/umask=0x3,event=0x4/
2,736 uncore_imc_1/umask=0x3,event=0x4/
2,671 uncore_imc_2/umask=0x3,event=0x4/
2,508 uncore_imc_3/umask=0x3,event=0x4/
2,439 uncore_imc_4/umask=0x3,event=0x4/
2,465 uncore_imc_5/umask=0x3,event=0x4/
0.004159243 seconds time elapsed
$ ./perf stat -a -e *imc/umask=0x3,event=0x4/ --no-merge ls -l >
/dev/null
Performance counter stats for 'system wide':
2,704 uncore_imc_0/umask=0x3,event=0x4/
2,601 uncore_imc_1/umask=0x3,event=0x4/
2,625 uncore_imc_2/umask=0x3,event=0x4/
2,370 uncore_imc_3/umask=0x3,event=0x4/
2,485 uncore_imc_4/umask=0x3,event=0x4/
2,431 uncore_imc_5/umask=0x3,event=0x4/
0.002716763 seconds time elapsed
$ ./perf stat -a -e imc*/umask=0x3,event=0x4/ --no-merge ls -l >
/dev/null
Performance counter stats for 'system wide':
1,294 uncore_imc_0/umask=0x3,event=0x4/
1,303 uncore_imc_1/umask=0x3,event=0x4/
1,242 uncore_imc_2/umask=0x3,event=0x4/
1,125 uncore_imc_3/umask=0x3,event=0x4/
1,137 uncore_imc_4/umask=0x3,event=0x4/
1,159 uncore_imc_5/umask=0x3,event=0x4/
0.002790441 seconds time elapsed
$ ./perf stat -a -e *imc*/umask=0x3,event=0x4/ --no-merge ls -l >
/dev/null
Performance counter stats for 'system wide':
1,524 uncore_imc_0/umask=0x3,event=0x4/
1,508 uncore_imc_1/umask=0x3,event=0x4/
1,501 uncore_imc_2/umask=0x3,event=0x4/
1,405 uncore_imc_3/umask=0x3,event=0x4/
1,427 uncore_imc_4/umask=0x3,event=0x4/
1,450 uncore_imc_5/umask=0x3,event=0x4/
0.002720907 seconds time elapsed
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2018-03-05 20:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-02 23:41 [RFC V2 0/3] perf stat: improvements for handling of multiple PMUs Agustin Vega-Frias
2018-03-02 23:41 ` [RFC V2 1/3] perf, tools: Support wildcards on pmu name in dynamic pmu events Agustin Vega-Frias
2018-03-03 14:34 ` Jiri Olsa
2018-03-04 17:12 ` Andi Kleen
2018-03-04 18:10 ` Jiri Olsa
2018-03-05 15:08 ` Agustin Vega-Frias
2018-03-05 17:55 ` Andi Kleen
2018-03-05 19:09 ` Jiri Olsa
2018-03-05 20:10 ` Agustin Vega-Frias [this message]
2018-03-05 21:51 ` Jiri Olsa
2018-03-02 23:41 ` [RFC V2 2/3] perf, tools: Display pmu name when printing unmerged events in stat Agustin Vega-Frias
2018-03-02 23:41 ` [RFC V2 3/3] perf pmu: Auto-merge PMU events created by prefix or glob match Agustin Vega-Frias
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=94ecc9b1337d15fe4634da56cb428738@codeaurora.org \
--to=agustinv@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).