From: Michael Ellerman <mpe@ellerman.id.au>
To: Ingo Molnar <mingo@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>, Jiri Olsa <jolsa@kernel.org>,
linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Thomas Gleixner <tglx@linutronix.de>,
Arnaldo Carvalho de Melo <acme@infradead.org>
Subject: Re: [PATCH 09/13] perf tools: Add perf download to download event files
Date: Wed, 06 Aug 2014 11:16:20 +1000 [thread overview]
Message-ID: <1407287780.32238.3.camel@concordia> (raw)
In-Reply-To: <20140719095104.GA11994@gmail.com>
On Sat, 2014-07-19 at 11:51 +0200, Ingo Molnar wrote:
> * Andi Kleen <andi@firstfloor.org> wrote:
>
> > Ingo Molnar <mingo@kernel.org> writes:
> > >
> > > We want these description files to be in the perf source code,
> > > somewhere in tools/perf/live-config/arch/x86/ or so, and installed
> > > during 'make install' - i.e. part of perf project and installed in
> > > ~/.debug or ~/.perf or so.
> >
> > I don't think that's a good idea. It would recreate all the
> > problems oprofile has with out of date event lists. Already
> > proven to not work well.
>
> That's true only if you ignore my second suggestion:
>
> > > Those files could be refreshed via 'perf download' and could be
> > > accessible via kernel.org as well, 'perf download' should pick up
> > > these files from Linus's latest git repository (via the HTTP
> > > namespace).
> >
> > I have doubts a gitweb server is a good way to distribute
> > potentially high volume / high access data.
>
> I don't buy that concern either, because typically humans will trigger
> the refresh - just like clicking on a link to refresh. In any case, if
> it starts being a problem in practice we can reconsider, it's not a
> reason to not do it.
>
> > However getting a more neutral space is fine.
> >
> > It would be fine to put it elsewhere on kernel.org.
> > I can ask for a space.
>
> The beauty of my approach is to:
>
> 1) integrate the descriptions into the project, so that developers
> are well aware of them and keep them uptodate - while considering
> all the other perf features the kernel may offer.
>
> 2) have them update automatically as we update the primary source, in
> a single place.
Another benefit of having the events installed as part of perf is that they are
usable on machines that don't have access to the internet.
Even if some of the event descriptions are out of date, that is still
preferable to having no events on such machines.
cheers
next prev parent reply other threads:[~2014-08-06 1:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 20:02 [GIT PULL 00/13] perf/core improvements and fixes Jiri Olsa
2014-07-16 20:02 ` [PATCH 01/13] perf tools: Enable close-on-exec flag on perf file descriptor Jiri Olsa
2014-07-16 20:02 ` [PATCH 02/13] perf tests: Update attr test with PERF_FLAG_FD_CLOEXEC flag Jiri Olsa
2014-07-16 20:02 ` [PATCH 03/13] perf tools: Add jsmn `jasmine' JSON parser Jiri Olsa
2014-07-16 20:02 ` [PATCH 04/13] perf tools: Add support for text descriptions of events and alias add Jiri Olsa
2014-07-16 20:02 ` [PATCH 05/13] perf tools: Update perf list to output descriptions Jiri Olsa
2014-07-16 20:02 ` [PATCH 06/13] perf tools: Allow events with dot Jiri Olsa
2014-07-16 20:02 ` [PATCH 07/13] perf tools: Add support for reading JSON event files Jiri Olsa
2014-07-16 20:02 ` [PATCH 08/13] perf tools: Automatically look for event file name for cpu Jiri Olsa
2014-07-16 20:02 ` [PATCH 09/13] perf tools: Add perf download to download event files Jiri Olsa
2014-07-17 10:47 ` Ingo Molnar
2014-07-17 10:51 ` Ingo Molnar
2014-07-18 17:35 ` Andi Kleen
2014-07-19 9:51 ` Ingo Molnar
2014-08-06 1:16 ` Michael Ellerman [this message]
2014-08-06 1:09 ` Michael Ellerman
2014-07-16 20:02 ` [PATCH 10/13] perf tools: Query terminal width and use in perf list Jiri Olsa
2014-07-16 20:02 ` [PATCH 11/13] perf tools: Add a new pmu interface to iterate over all events Jiri Olsa
2014-07-16 20:02 ` [PATCH 12/13] perf tests: Add test case for alias and JSON parsing Jiri Olsa
2014-07-16 20:02 ` [PATCH 13/13] perf tools: Add a --no-desc flag to perf list 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=1407287780.32238.3.camel@concordia \
--to=mpe@ellerman.id.au \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=acme@kernel.org \
--cc=andi@firstfloor.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
/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).