From: Arun Sharma <asharma@fb.com>
To: Robert Richter <robert.richter@amd.com>
Cc: peterz@infradead.org, Anton Blanchard <anton@au1.ibm.com>,
linux-kernel@vger.kernel.org, eranian@google.com,
acme@redhat.com, linuxppc-dev@ozlabs.org, paulus@samba.org,
mpjohn@us.ibm.com,
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
mingo@kernel.org
Subject: Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events
Date: Mon, 15 Oct 2012 10:23:10 -0700 [thread overview]
Message-ID: <507C467E.8010205@fb.com> (raw)
In-Reply-To: <20121015155534.GR8285@erda.amd.com>
On 10/15/12 8:55 AM, Robert Richter wrote:
[..]
> Perf tool works then out-of-the-box with:
>
> $ perf record -e cpu/stalled-cycles-fixed-point/ ...
>
> The event string can easily be reused by other architectures as a
> quasi standard.
I like Robert's proposal better. It's hard to model all the stall events
(eg: instruction decoder related stalls on x86) in a hardware
independent way.
Another area to think about: software engineers are generally busy and
have a limited amount of time to devote to hardware event based
optimizations. The most common question I hear is: what is the expected
perf gain if I fix this? It's hard to answer that with just the stall
events.
-Arun
WARNING: multiple messages have this Message-ID (diff)
From: Arun Sharma <asharma@fb.com>
To: Robert Richter <robert.richter@amd.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
<acme@redhat.com>, <mingo@kernel.org>, <peterz@infradead.org>,
<eranian@google.com>, "Anton Blanchard" <anton@au1.ibm.com>,
<paulus@samba.org>, <mpjohn@us.ibm.com>,
<linuxppc-dev@ozlabs.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events
Date: Mon, 15 Oct 2012 10:23:10 -0700 [thread overview]
Message-ID: <507C467E.8010205@fb.com> (raw)
In-Reply-To: <20121015155534.GR8285@erda.amd.com>
On 10/15/12 8:55 AM, Robert Richter wrote:
[..]
> Perf tool works then out-of-the-box with:
>
> $ perf record -e cpu/stalled-cycles-fixed-point/ ...
>
> The event string can easily be reused by other architectures as a
> quasi standard.
I like Robert's proposal better. It's hard to model all the stall events
(eg: instruction decoder related stalls on x86) in a hardware
independent way.
Another area to think about: software engineers are generally busy and
have a limited amount of time to devote to hardware event based
optimizations. The most common question I hear is: what is the expected
perf gain if I fix this? It's hard to answer that with just the stall
events.
-Arun
next prev parent reply other threads:[~2012-10-15 17:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-12 1:28 [RFC][PATCH] perf: Add a few generic stalled-cycles events Sukadev Bhattiprolu
2012-10-12 1:28 ` Sukadev Bhattiprolu
2012-10-15 5:26 ` Anshuman Khandual
2012-10-15 5:26 ` Anshuman Khandual
2012-10-15 15:55 ` Robert Richter
2012-10-15 15:55 ` Robert Richter
2012-10-15 17:23 ` Arun Sharma [this message]
2012-10-15 17:23 ` Arun Sharma
2012-10-16 5:28 ` Anshuman Khandual
2012-10-16 5:28 ` Anshuman Khandual
2012-10-16 10:08 ` Robert Richter
2012-10-16 10:08 ` Robert Richter
2012-10-16 12:21 ` Stephane Eranian
2012-10-16 12:21 ` Stephane Eranian
2012-10-19 17:05 ` Sukadev Bhattiprolu
2012-10-19 17:05 ` Sukadev Bhattiprolu
2012-10-16 18:31 ` Sukadev Bhattiprolu
2012-10-16 18:31 ` Sukadev Bhattiprolu
2012-10-24 12:27 ` Peter Zijlstra
2012-10-24 12:27 ` Peter Zijlstra
2012-10-31 6:40 ` Sukadev Bhattiprolu
2012-10-31 6:40 ` Sukadev Bhattiprolu
2012-10-31 7:22 ` Peter Zijlstra
2012-10-31 7:22 ` 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=507C467E.8010205@fb.com \
--to=asharma@fb.com \
--cc=acme@redhat.com \
--cc=anton@au1.ibm.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@kernel.org \
--cc=mpjohn@us.ibm.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
--cc=sukadev@linux.vnet.ibm.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 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.