Re: perf_arch_fetch_caller_regs...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 18, 2010 at 09:02:41PM -0700, David Miller wrote:
> 
> Can we please remove the CALLER_ADDR0 et al. evaluations at the top
> level in perf_fetch_caller_regs()?
> 
> I take great pains to avoid having to flush the register windows on
> sparc64 even when fetching callchains et al and any
> __builtin_return_address() with an argument greater than zero is going
> to force a register window flush to get emitted by gcc undoing all of
> my hard work :-)
> 
> You guys can put it into the x86 perf_fetch_caller_regs() or similar.
> 
> If you need it to be evaluated at the call site, make the inline
> overridable by the platform headers.
> 
> I noticed that the powerpc assembler Paul posted the past few days
> ignores this "ip" arg passed down and computes it by hand as it
> walks up the stack chain in assembler.  PowerPC therefore might be
> getting similar inefficiences due to this CALLER_ADDR? stuff.

Well, it would except that CALLER_ADDR1, 2, etc. turn into (0) on
powerpc because we use the generic definition and we don't define
CONFIG_FRAME_POINTER (it's meaningless on powerpc because the ABI
defines that each stack frame always has a pointer to the previous
frame).

I should fix CALLER_ADDRx on powerpc one day, then we will have the
extra inefficiency.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux