All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
	mingo@redhat.com, Jiri Olsa <jolsa@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	peterz@infradead.org, namhyung@kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	Pekka Enberg <penberg@iki.fi>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Borislav Petkov <bp@alien8.de>
Subject: Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.)
Date: Wed, 15 Apr 2015 12:17:34 -0700	[thread overview]
Message-ID: <20150415191734.GC15335@tassilo.jf.intel.com> (raw)
In-Reply-To: <20150415092557.GA14942@gmail.com>

> My suggestion to resolve the technical objections and lift the NAK 
> would be:
> 
>  - to add the tables to the source code, in a more human readable 
>    format and (optionally) structure the event names better into a 
>    higher level hierarchy, than the humungous linear dumps with no 
>    explanations that you propose - while still supporting the 'raw' 
>    vendor event names you want to use, for those people who are used 
>    to them.

Trying to understand what you mean with high level hierarchy:

Do you mean something like the oprofile event / unit mask split,
with events having a default unit mask?

This one actually works poorly for modern Intel systems, as
unit masks can completely change the behavior, so there is 
not necessarily a direct relation between the name before the dot and the one
after, or a concept of a "default" unit mask.

Or do you mean someone creating a tree hierarchy of events to systematically
debug some particular problem?

I implemented this in my toplev tool here:
https://github.com/andikleen/pmu-tools/wiki/toplev-manual
http://github.com/andikleen/pmu-tools

But it's quite complicated and cannot really be done portable in
a full way without completely turning perf into an architecture specific
tool (which I assume you're opposed to)

Or just some sections grouping events into different topics?
"branches", "caches", "execution" or somesuch.

I think this could be done with the JSON format. Just add a new header.
Print them as sections in perf list.

Or do you mean something like the perf cache events tables?
We already have those. But they cannot replace direct micro architectural
specific events, as the cache event tables do not necessarily express
everything a given micro architecture supports. And also there is a lot
of documentation using the vendor event names, which the users
then want to use.

If it's something else please explain.

> 
>  - to pre-parse the event descriptions at build time - beyond the 
>    speedup 

FWIW I just measured it and the overhead parse time for the haswell JSON file on
my laptop is about 33ms. 

# with event map
% time ./obj-perf/perf list > /dev/null
real    0m0.045s
user    0m0.041s
sys     0m0.003s

% export EVENTMAP=/dev/zero
% time perf list > /dev/null

real    0m0.011s
user    0m0.004s
sys     0m0.006s


>  - to upgrade perf as a whole unit: this helps not just your usecase
>    but many other usecases as well.

With the downloader it actually automatically downloads any missing
files, so the upgrading just works.

-Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@linux.intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	peterz@infradead.org, linuxppc-dev@lists.ozlabs.org,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	mingo@redhat.com, Borislav Petkov <bp@alien8.de>,
	namhyung@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
	Jiri Olsa <jolsa@redhat.com>, Pekka Enberg <penberg@iki.fi>
Subject: Re: 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.)
Date: Wed, 15 Apr 2015 12:17:34 -0700	[thread overview]
Message-ID: <20150415191734.GC15335@tassilo.jf.intel.com> (raw)
In-Reply-To: <20150415092557.GA14942@gmail.com>

> My suggestion to resolve the technical objections and lift the NAK 
> would be:
> 
>  - to add the tables to the source code, in a more human readable 
>    format and (optionally) structure the event names better into a 
>    higher level hierarchy, than the humungous linear dumps with no 
>    explanations that you propose - while still supporting the 'raw' 
>    vendor event names you want to use, for those people who are used 
>    to them.

Trying to understand what you mean with high level hierarchy:

Do you mean something like the oprofile event / unit mask split,
with events having a default unit mask?

This one actually works poorly for modern Intel systems, as
unit masks can completely change the behavior, so there is 
not necessarily a direct relation between the name before the dot and the one
after, or a concept of a "default" unit mask.

Or do you mean someone creating a tree hierarchy of events to systematically
debug some particular problem?

I implemented this in my toplev tool here:
https://github.com/andikleen/pmu-tools/wiki/toplev-manual
http://github.com/andikleen/pmu-tools

But it's quite complicated and cannot really be done portable in
a full way without completely turning perf into an architecture specific
tool (which I assume you're opposed to)

Or just some sections grouping events into different topics?
"branches", "caches", "execution" or somesuch.

I think this could be done with the JSON format. Just add a new header.
Print them as sections in perf list.

Or do you mean something like the perf cache events tables?
We already have those. But they cannot replace direct micro architectural
specific events, as the cache event tables do not necessarily express
everything a given micro architecture supports. And also there is a lot
of documentation using the vendor event names, which the users
then want to use.

If it's something else please explain.

> 
>  - to pre-parse the event descriptions at build time - beyond the 
>    speedup 

FWIW I just measured it and the overhead parse time for the haswell JSON file on
my laptop is about 33ms. 

# with event map
% time ./obj-perf/perf list > /dev/null
real    0m0.045s
user    0m0.041s
sys     0m0.003s

% export EVENTMAP=/dev/zero
% time perf list > /dev/null

real    0m0.011s
user    0m0.004s
sys     0m0.006s


>  - to upgrade perf as a whole unit: this helps not just your usecase
>    but many other usecases as well.

With the downloader it actually automatically downloads any missing
files, so the upgrading just works.

-Andi

  reply	other threads:[~2015-04-15 19:17 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-14  6:40 [PATCH v9 00/11] Add support for JSON event files Sukadev Bhattiprolu
2015-04-14  6:40 ` Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 01/11] perf, tools: Add jsmn `jasmine' JSON parser Sukadev Bhattiprolu
2015-04-14  6:40   ` Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 02/11] perf, tools: Add support for text descriptions of events and alias add Sukadev Bhattiprolu
2015-04-14  6:40   ` Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 03/11] perf, tools, list: Update perf list to output descriptions Sukadev Bhattiprolu
2015-04-14  6:40   ` Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 04/11] perf, tools: Add support for reading JSON event files Sukadev Bhattiprolu
2015-04-14  6:40   ` Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 05/11] perf, tools: Automatically look for event file name for cpu Sukadev Bhattiprolu
2015-04-14  6:40   ` Sukadev Bhattiprolu
2015-04-14  6:40 ` [PATCH v9 06/11] powerpc/perf: Implement get_cpu_str() Sukadev Bhattiprolu
2015-04-14  6:40   ` Sukadev Bhattiprolu
2015-04-14  6:41 ` [PATCH v9 07/11] perf, tools: Query terminal width and use in perf list Sukadev Bhattiprolu
2015-04-14  6:41   ` Sukadev Bhattiprolu
2015-04-14  6:41 ` [PATCH v9 08/11] perf, tools: Add a new pmu interface to iterate over all events Sukadev Bhattiprolu
2015-04-14  6:41   ` Sukadev Bhattiprolu
2015-04-14  6:41 ` [PATCH v9 09/11] perf, tools, test: Add test case for alias and JSON parsing Sukadev Bhattiprolu
2015-04-14  6:41   ` Sukadev Bhattiprolu
2015-04-14  6:41 ` [PATCH v9 10/11] perf, tools: Add a --no-desc flag to perf list Sukadev Bhattiprolu
2015-04-14  6:41   ` Sukadev Bhattiprolu
2015-04-14  6:41 ` [PATCH v9 11/11] perf-download: Download the events json file Sukadev Bhattiprolu
2015-04-14  6:41   ` Sukadev Bhattiprolu
2015-04-14  8:55 ` 'perf upgrade' (was: Re: [PATCH v9 00/11] Add support for JSON event files.) Ingo Molnar
2015-04-14  8:55   ` Ingo Molnar
2015-04-14 11:21   ` Michael Ellerman
2015-04-14 11:21     ` Michael Ellerman
2015-04-14 12:58     ` Ingo Molnar
2015-04-14 12:58       ` Ingo Molnar
2015-04-14 18:03       ` Sukadev Bhattiprolu
2015-04-14 18:03         ` Sukadev Bhattiprolu
2015-04-14 22:53       ` Michael Ellerman
2015-04-14 22:53         ` Michael Ellerman
2015-04-15  9:25         ` Ingo Molnar
2015-04-15  9:25           ` Ingo Molnar
2015-04-15 19:17           ` Andi Kleen [this message]
2015-04-15 19:17             ` Andi Kleen
2015-04-15 20:50           ` Sukadev Bhattiprolu
2015-04-15 20:50             ` Sukadev Bhattiprolu
2015-04-17 15:31             ` Jiri Olsa
2015-04-17 15:31               ` Jiri Olsa
2015-04-17 20:09               ` Andi Kleen
2015-04-17 20:09                 ` Andi Kleen
2015-04-18 13:05                 ` Jiri Olsa
2015-04-18 13:05                   ` Jiri Olsa
2015-04-18 13:12             ` Jiri Olsa
2015-04-18 13:12               ` Jiri Olsa
2015-04-14 20:16   ` Andi Kleen
2015-04-14 20:16     ` Andi Kleen

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=20150415191734.GC15335@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=acme@kernel.org \
    --cc=bp@alien8.de \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=namhyung@kernel.org \
    --cc=penberg@iki.fi \
    --cc=peterz@infradead.org \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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 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.