BTW the whole discussion is rather pointless.
We have to profile the software as it is, not as we wish it to be.
That means: small functions, often no frame pointer, all kinds of crappy
code and missing information.
And then doing it all with as little overhead as possible.
I think on these me
On Wed, Apr 09, 2014 at 01:48:57PM +0200, Peter Zijlstra wrote:
> On Wed, Feb 26, 2014 at 12:26:43PM -0800, Andy Lutomirski wrote:
> > Speed. FPO saves one register (a big deal on x86_32; not so important
> > on x86_64) but also saves a few cycles on function entry and exit,
> > which is a bigger
On Wed, Feb 26, 2014 at 12:26:43PM -0800, Andy Lutomirski wrote:
> Speed. FPO saves one register (a big deal on x86_32; not so important
> on x86_64) but also saves a few cycles on function entry and exit,
> which is a bigger deal for small functions.
So I though that LTO was supposed to get rid
On Thu, Feb 27, 2014 at 01:35:07PM +0100, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
> > On Wed, Feb 26, 2014 at 10:55 AM, Andi Kleen wrote:
> >
> > >> I'm suggesting a perf event option, just like the way that PEBS
> > >> works.
> > >
> > > Right now it's a somewhat experimental featur
* Andy Lutomirski wrote:
> On Wed, Feb 26, 2014 at 10:55 AM, Andi Kleen wrote:
>
> >> I'm suggesting a perf event option, just like the way that PEBS
> >> works.
> >
> > Right now it's a somewhat experimental feature and just having the
> > sysctl is fine. [...]
NACKed-by: Ingo Molnar
> >
On Wed, Feb 26, 2014 at 10:42 PM, Andi Kleen wrote:
> On Wed, Feb 26, 2014 at 02:34:31PM -0700, David Ahern wrote:
>> On 2/26/14, 1:53 PM, Andi Kleen wrote:
>> >>Is there some reason not to enable frame pointers?
>> >
>> >It makes code slower.
>>
That is what I have been told by compiler people t
On Wed, Feb 26, 2014 at 02:34:31PM -0700, David Ahern wrote:
> On 2/26/14, 1:53 PM, Andi Kleen wrote:
> >>Is there some reason not to enable frame pointers?
> >
> >It makes code slower.
>
> Sure there is some overhead because of the push, mov, pop
> instructions per function. But, take for example
On 2/26/14, 1:53 PM, Andi Kleen wrote:
Is there some reason not to enable frame pointers?
It makes code slower.
Sure there is some overhead because of the push, mov, pop instructions
per function. But, take for example the simple program below. Compile
with and without frame pointers
gcc
> > Another issue is that you can't enable it on a lot of existing
> > libraries, sometimes not even with a recompile. For example
> > glibc assembler functions do not support it at all, which
> > is a very common case.
>
> They're mostly all leaf functions, so it doesn't matter much if
> anything
On Wed, Feb 26, 2014 at 09:53:22PM +0100, Andi Kleen wrote:
> > Is there some reason not to enable frame pointers?
>
> It makes code slower.
>
> Especially on Atom CPUs, where it causes pipeline stalls, but
Yeah, but nobody sane cares about the in-order atom crap CPUs.
> also to some degree on
> Is there some reason not to enable frame pointers?
It makes code slower.
Especially on Atom CPUs, where it causes pipeline stalls, but
also to some degree on others, because you lose one register and
spend a little bit of time setting it up, so making small
functions more expensive.
Another is
On Wed, Feb 26, 2014 at 01:14:58PM -0700, David Ahern wrote:
> Does WRL or Yocto fall into that 'standard distro' comment? Fairly easy to
> enable frame-pointers.
Yeah, same for Gentoo, I always build world with frame-pointers enabled.
--
To unsubscribe from this list: send the line "unsubscribe l
On Wed, Feb 26, 2014 at 12:14 PM, David Ahern wrote:
> On 2/26/14, 12:25 PM, Andy Lutomirski wrote:
>>
>> On Wed, Feb 26, 2014 at 11:19 AM, David Ahern wrote:
>>>
>>> On 2/26/14, 11:59 AM, Andy Lutomirski wrote:
>>>
I wonder if anyone who uses perf for userspace profiling *ever* uses
FP
On 2/26/14, 12:25 PM, Andy Lutomirski wrote:
On Wed, Feb 26, 2014 at 11:19 AM, David Ahern wrote:
On 2/26/14, 11:59 AM, Andy Lutomirski wrote:
I wonder if anyone who uses perf for userspace profiling *ever* uses
FP and gets away with it. There's precious little userspace software
compiled wi
On Wed, Feb 26, 2014 at 11:19 AM, David Ahern wrote:
> On 2/26/14, 11:59 AM, Andy Lutomirski wrote:
>
>> I wonder if anyone who uses perf for userspace profiling *ever* uses
>> FP and gets away with it. There's precious little userspace software
>> compiled with frame pointers these days on most
On 2/26/14, 11:59 AM, Andy Lutomirski wrote:
I wonder if anyone who uses perf for userspace profiling *ever* uses
FP and gets away with it. There's precious little userspace software
compiled with frame pointers these days on most architectures.
yes and yes. With control over the entire stack
On Wed, Feb 26, 2014 at 10:55 AM, Andi Kleen wrote:
>> I'm suggesting a perf event option, just like the way that PEBS works.
>
> Right now it's a somewhat experimental feature and just having
> the sysctl is fine. If it turns out that is what everyone uses
> such an option could be still added la
> I'm suggesting a perf event option, just like the way that PEBS works.
Right now it's a somewhat experimental feature and just having
the sysctl is fine. If it turns out that is what everyone uses
such an option could be still added later.
I suspect most people would still use FP if they can,
On Wed, Feb 26, 2014 at 12:04 AM, Stephane Eranian wrote:
> On Wed, Feb 26, 2014 at 3:39 AM, Andy Lutomirski wrote:
>> On 02/17/2014 10:07 PM, Yan, Zheng wrote:
>>>
>>> This patch series adds LBR call stack support. User can enabled/disable
>>> this through an sysfs attribute file in the CPU PMU
On 02/26/2014 03:04 PM, Stephane Eranian wrote:
> On Wed, Feb 26, 2014 at 3:39 AM, Andy Lutomirski wrote:
>> On 02/17/2014 10:07 PM, Yan, Zheng wrote:
>>>
>>> This patch series adds LBR call stack support. User can enabled/disable
>>> this through an sysfs attribute file in the CPU PMU directory:
On Wed, Feb 26, 2014 at 3:39 AM, Andy Lutomirski wrote:
> On 02/17/2014 10:07 PM, Yan, Zheng wrote:
>>
>> This patch series adds LBR call stack support. User can enabled/disable
>> this through an sysfs attribute file in the CPU PMU directory:
>> echo 1 > /sys/bus/event_source/devices/cpu/lbr_cal
On 02/17/2014 10:07 PM, Yan, Zheng wrote:
>
> This patch series adds LBR call stack support. User can enabled/disable
> this through an sysfs attribute file in the CPU PMU directory:
> echo 1 > /sys/bus/event_source/devices/cpu/lbr_callstack
This seems like an unpleasant way to control this. I
Your patches still only have 3-4 lines of Changelog, I'll continue
ignoring them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
On 02/24/2014 03:47 AM, Stephane Eranian wrote:
> Could you add the Reviewed-by: on the patches I already
> reviewed? So I focus on the changes you made and continue
> testing on my HSW system.
>
Hi,
I got your Reviewed-by for patch 1,5,6,8. Patch 6 was changed in this series.
So only patch 1,6,8
Could you add the Reviewed-by: on the patches I already
reviewed? So I focus on the changes you made and continue
testing on my HSW system.
Thanks.
On Tue, Feb 18, 2014 at 7:07 AM, Yan, Zheng wrote:
> For many profiling tasks we need the callgraph. For example we often
> need to see the caller o
25 matches
Mail list logo
