From: Ingo Molnar <mingo@kernel.org>
To: Stephane Eranian <eranian@google.com>
Cc: Jiri Olsa <jolsa@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
Corey Ashford <cjashfor@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@elte.hu>, Namhyung Kim <namhyung@kernel.org>,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 1/8] perf tools: Add '.' as part of the event 'name' token
Date: Tue, 29 Jan 2013 09:03:05 +0100 [thread overview]
Message-ID: <20130129080305.GB594@gmail.com> (raw)
In-Reply-To: <CABPqkBTPHKf+XTmeyA8PrWReG8Ak6ow9gSwfh4ozK+gvJMze1w@mail.gmail.com>
* Stephane Eranian <eranian@google.com> wrote:
> On Mon, Jan 28, 2013 at 9:52 PM, Stephane Eranian <eranian@google.com> wrote:
> > Jiri,
> >
> > I don't see part 0/8 of this series. Did you send it to me too?
> >
> > I have some comments about it. I don't see why create something from scratch
> > when I have been developing a library (libpfm4) that takes care of that and that
> > is already used by many tool developers. That library can be linked with perf
> > and provide full symbolic events + all the modifiers. The library is portable
> > and supports all existing archs. It can also be used by self-monitoring apps.
> >
> >
> > You're introducing yet another event table to maintain. And believe me this is
> > a lot of work to maintain this.
> >
> > I don't understand why not use this existing library.
> >
>
> I meant to add that I think it would be more productive if we
> (you and I) were to work on the library to extend it with
> external text-based event tables that could be used by perf
> either directly or thru the libpfm4 interface.
perf is intentionally external file free and does not
(fundamentally) depend on external libraries either,
other than core system libraries.
There are several advantages to that:
- there is no version skew and no design/maintenance friction
- 'upgrading' perf between similar boxes is as simple as
copying the perf binary
- it's self-sufficient
- there's no real advantage of external text files versus
internal text files (i.e. text tables within the source
code), while there are several disadvantages
So as long as Jiri is happy to maintain these tables I think
it's a superior solution (even if the tables start out
incomplete), from the perf project's perspective.
Thanks,
Ingo
next prev parent reply other threads:[~2013-01-29 8:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-26 20:04 [RFCv2 0/8] perf tools: Add non-architectural event aliases Jiri Olsa
2013-01-26 20:04 ` [PATCH 1/8] perf tools: Add '.' as part of the event 'name' token Jiri Olsa
2013-01-28 20:52 ` Stephane Eranian
2013-01-28 21:32 ` Stephane Eranian
2013-01-29 8:03 ` Ingo Molnar [this message]
2013-01-29 10:53 ` Jiri Olsa
2013-02-03 20:37 ` Stephane Eranian
2013-02-04 7:30 ` Jiri Olsa
2013-05-03 18:56 ` Peter Zijlstra
2013-05-04 8:10 ` Ingo Molnar
2013-01-26 20:04 ` [PATCH 2/8] perf tools: Change perf_pmu__new_alias function interface Jiri Olsa
2013-01-26 20:04 ` [PATCH 3/8] perf tools: Add name term processing for alias Jiri Olsa
2013-01-26 20:04 ` [PATCH 4/8] perf tools: Add pmu interface to parse single file of aliases Jiri Olsa
2013-01-26 20:04 ` [PATCH 5/8] perf tools: Add support to include non architectural event aliases Jiri Olsa
2013-01-26 20:04 ` [PATCH 6/8] perf tools: Add non arch events for SandyBridge microarchitecture Jiri Olsa
2013-01-26 20:04 ` [PATCH 7/8] perf tools: Add non arch events for IvyBridge micro architecture Jiri Olsa
2013-01-26 20:04 ` [PATCH 8/8] perf tools: List kernel supplied event aliases in perf list v2 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=20130129080305.GB594@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung@kernel.org \
--cc=paulus@samba.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).