From: Jiri Olsa <jolsa@redhat.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>,
"Yan, Zheng" <zheng.z.yan@intel.com>,
mingo@elte.hu
Cc: mingo@elte.hu, andi@firstfloor.org, eranian@google.com,
ming.m.lin@intel.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 9/9] perf tool: Add pmu event alias support
Date: Thu, 3 May 2012 22:05:18 +0200 [thread overview]
Message-ID: <20120503200518.GC1671@m.brq.redhat.com> (raw)
In-Reply-To: <1336044261.22523.11.camel@twins>
On Thu, May 03, 2012 at 01:24:21PM +0200, Peter Zijlstra wrote:
> On Thu, 2012-05-03 at 12:56 +0200, Jiri Olsa wrote:
> > - in sysfs you would have directory with aliases (now called 'events')
> > - each alias is sysfs dir, with file attrs:
> > file name = term name, file value = term value
> > eg.:
> > events/
> > CAS_COUNT_RD/
> > # files:
> > config - value 1
> > config1 - value 2
> > mask - value ...
>
> I'd prefer the thing Yan proposed (if the sysfs folks let us),
>
> $foo/events/QHL_REQUEST_REMOTE_READS
>
> with contents: "event=0x20,umask=0x4"
>
> > this way it's also possible to add extra terms to existing alias
> > in command line if needed... might be handy
> >
> That should always be possible, if you modify the parser to take things
> like:
>
> event=0x20,umask=0x4,event=0x21
>
> and have latter values override earlier values, so it collapses into:
>
> umask=0x4,event=0x21
>
> you can simply take whatever comes out of the event file and stick extra
> bits at the end.
I discussed this with Peter on irc, so I'll try to sum it up
we have following options so far:
with event alias 'al' with definition 'config=1,config1=1,config2=2'
1) inside parse_events_add_pmu function
once alias term is detected as part of event definition 'pmu/al/mod' we
construct new event 'pmu/config=1,config1=1,config2=2/mod' and rerun the
event parser on that
2) inside parse_events_add_pmu function
once alias term is detected as part of event definition 'pmu/al/mod' we
replace that term with list of terms for that alias definition and run
perf_pmu__config with this new term list
3) during bison/flex processing
have option 2) embeded inside flex/bison rules. Once alias term
is detected, insert the aliased terms directly to the list of terms,
not replacing expos as in option 2.
- option 1 is currently implemented
- options 2 and 3 requires the aliased config is loaded/parsed from pmu
sysfs tree in form of terms list
- option 3 is a little fuzzy for me now on how to integrate this with
flex/bison
My interest here is to go with option 2 or 3 if possible - preferrably 2 ;),
because I think it's better/cleaner to deal with terms in one place once they
are parsed - in parse_events_add_pmu function.
I think there's no need to re run the whole parser (option 1) when we
have the whole thing ready by adding just extra terms.
thoughts?
thanks,
jirka
next prev parent reply other threads:[~2012-05-03 20:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 2:07 [PATCH V3 0/9] perf: Intel uncore pmu counting support Yan, Zheng
2012-05-02 2:07 ` [PATCH 1/9] perf: Export perf_assign_events Yan, Zheng
2012-05-02 2:07 ` [PATCH 2/9] perf: Allow pmu to choose cpu on which to install event Yan, Zheng
2012-05-09 6:38 ` Anshuman Khandual
2012-05-10 1:09 ` Yan, Zheng
2012-05-10 3:41 ` Anshuman Khandual
2012-05-10 10:56 ` Peter Zijlstra
2012-05-02 2:07 ` [PATCH 3/9] perf: Introduce perf_pmu_migrate_context Yan, Zheng
2012-05-02 2:07 ` [PATCH 4/9] perf: Generic intel uncore support Yan, Zheng
2012-05-03 17:12 ` Peter Zijlstra
2012-05-04 7:33 ` Yan, Zheng
2012-05-04 17:57 ` Peter Zijlstra
2012-05-10 7:34 ` Yan, Zheng
2012-05-10 10:05 ` Peter Zijlstra
2012-05-11 1:54 ` Yan, Zheng
2012-05-03 21:49 ` Peter Zijlstra
2012-05-11 6:31 ` Anshuman Khandual
2012-05-11 6:41 ` Yan, Zheng
2012-05-02 2:07 ` [PATCH 5/9] perf: Add Nehalem and Sandy Bridge " Yan, Zheng
2012-05-03 21:04 ` Peter Zijlstra
2012-05-04 5:47 ` Yan, Zheng
2012-05-03 21:04 ` Peter Zijlstra
2012-05-02 2:07 ` [PATCH 6/9] perf: Generic pci uncore device support Yan, Zheng
2012-05-03 21:37 ` Peter Zijlstra
2012-05-03 21:39 ` Peter Zijlstra
2012-05-03 21:46 ` Peter Zijlstra
2012-05-04 6:07 ` Yan, Zheng
2012-05-02 2:07 ` [PATCH 7/9] perf: Add Sandy Bridge-EP uncore support Yan, Zheng
2012-05-03 21:12 ` Peter Zijlstra
2012-05-02 2:07 ` [PATCH 8/9] perf tool: Make the event parser reentrantable Yan, Zheng
2012-05-02 2:07 ` [PATCH 9/9] perf tool: Add pmu event alias support Yan, Zheng
2012-05-03 10:56 ` Jiri Olsa
2012-05-03 11:24 ` Peter Zijlstra
2012-05-03 20:05 ` Jiri Olsa [this message]
2012-05-04 12:32 ` Yan, Zheng
2012-05-07 8:34 ` Yan, Zheng
2012-05-10 9:52 ` Jiri Olsa
2012-05-07 17:14 ` Peter Zijlstra
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=20120503200518.GC1671@m.brq.redhat.com \
--to=jolsa@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=andi@firstfloor.org \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=zheng.z.yan@intel.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 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).