All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Arun Sharma <asharma@fb.com>
Cc: linuxppc-dev@ozlabs.org, Robert Richter <robert.richter@amd.com>,
	Anton Blanchard <anton@au1.ibm.com>,
	linux-kernel@vger.kernel.org, eranian@google.com,
	acme@redhat.com, peterz@infradead.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: Tue, 16 Oct 2012 10:58:56 +0530	[thread overview]
Message-ID: <507CF098.9080703@linux.vnet.ibm.com> (raw)
In-Reply-To: <507C467E.8010205@fb.com>

On 10/15/2012 10:53 PM, Arun Sharma wrote:
> 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.
> 

Hardware event based optimization is a very important aspect of real world application
tuning. CPI stack analysis is a good reason why perf should have stall events as generic
ones. But I am not clear on situations where we consider adding these new generic events
into linux/perf_event.h and the situations where we should go with the sys fs interface.
Could you please elaborate on this ?

Regards
Anshuman

WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Arun Sharma <asharma@fb.com>
Cc: Robert Richter <robert.richter@amd.com>,
	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: Tue, 16 Oct 2012 10:58:56 +0530	[thread overview]
Message-ID: <507CF098.9080703@linux.vnet.ibm.com> (raw)
In-Reply-To: <507C467E.8010205@fb.com>

On 10/15/2012 10:53 PM, Arun Sharma wrote:
> 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.
> 

Hardware event based optimization is a very important aspect of real world application
tuning. CPI stack analysis is a good reason why perf should have stall events as generic
ones. But I am not clear on situations where we consider adding these new generic events
into linux/perf_event.h and the situations where we should go with the sys fs interface.
Could you please elaborate on this ?

Regards
Anshuman


  reply	other threads:[~2012-10-16  5:28 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
2012-10-15 17:23     ` Arun Sharma
2012-10-16  5:28     ` Anshuman Khandual [this message]
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=507CF098.9080703@linux.vnet.ibm.com \
    --to=khandual@linux.vnet.ibm.com \
    --cc=acme@redhat.com \
    --cc=anton@au1.ibm.com \
    --cc=asharma@fb.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.