Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1400700 > unrolled thread

Stack trace of csum_partial_copy_generic

Back to article view | Back to linux.kernel

Contents

  Stack trace of csum_partial_copy_generic Nikolay Borisov <kernel@kyup.com> - 2016-05-13 13:10 +0200
    Re: Stack trace of csum_partial_copy_generic Josh Poimboeuf <jpoimboe@redhat.com> - 2016-05-16 20:30 +0200

#1400700 — Stack trace of csum_partial_copy_generic

Hello Josh, 

I'd like to ask you whether objtool is supposed to produce a 
warning when arch/x86/lib/csum-copy_64.o (produced from 
arch/x86/lib/csum-copy_64.S). Since I cannot see any specific 
usage of rbp for defining a stackframe. I'm chasing against 
poor performance of a network benchmark and this is what perf produces: 

# Overhead          Command          Shared Object                                         Symbol
# ........  ...............  .....................  .............................................
#
    37.30%            iperf  [kernel.kallsyms]      [k] csum_partial_copy_generic                
                      |
                      --- csum_partial_copy_generic
                         |          
                         |--99.98%-- 0x7f809108b7cd
                         |          |          
                         |          |--69.72%-- 0x20000
                         |          |          
                         |           --30.28%-- 0x7f809108b7c2
                         |                     0x20000
                          --0.02%-- [...]

So this is not very helpful in tracing where this is being 
called from. Presumably somewhere from the networking layer. So 
should objtool catch this or since csum_partial_copy_generic is a leaf
function reliable stack trace isn't needed? Furthermore this function 
is called from C wrapper in csum-wrappers_64.c - shouldn't at least
they be present in the callstack?

This is on 4.6 master from linus and CONFIG_FRAME_POINTER being enabled. 

Regards, 
Nikolay

[toc] | [next] | [standalone]

#1401680

Hi Nikolay,

On Fri, May 13, 2016 at 02:07:47PM +0300, Nikolay Borisov wrote:
> Hello Josh, 
> 
> I'd like to ask you whether objtool is supposed to produce a 
> warning when arch/x86/lib/csum-copy_64.o (produced from 
> arch/x86/lib/csum-copy_64.S). Since I cannot see any specific 
> usage of rbp for defining a stackframe. I'm chasing against 
> poor performance of a network benchmark and this is what perf produces: 
> 
> # Overhead          Command          Shared Object                                         Symbol
> # ........  ...............  .....................  .............................................
> #
>     37.30%            iperf  [kernel.kallsyms]      [k] csum_partial_copy_generic                
>                       |
>                       --- csum_partial_copy_generic
>                          |          
>                          |--99.98%-- 0x7f809108b7cd
>                          |          |          
>                          |          |--69.72%-- 0x20000
>                          |          |          
>                          |           --30.28%-- 0x7f809108b7c2
>                          |                     0x20000
>                           --0.02%-- [...]
> 
> So this is not very helpful in tracing where this is being 
> called from. Presumably somewhere from the networking layer. So 
> should objtool catch this or since csum_partial_copy_generic is a leaf
> function reliable stack trace isn't needed?

Right, since it's a leaf function, objtool ignores it and lets it do
whatever it wants with the frame pointer.

> Furthermore this function is called from C wrapper in
> csum-wrappers_64.c - shouldn't at least they be present in the
> callstack?

I suspect the problem is that it can't walk the stack because the
function overwrites the rbp register.  Try replacing all uses of rbp in
that function with another register.  r15?

(Another solution would be to tell perf to use DWARF unwinding instead
of frame pointers, but currently, kernel asm code doesn't have any DWARF
annotations.  I'm planning on adding support for that soon in the 4.8
timeframe by generating DWARF metadata using objtool.)

-- 
Josh

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web