linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William Cohen <wcohen@redhat.com>
To: William Cohen <wcohen@redhat.com>,
	"linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>
Cc: wcohen@redhat.com
Subject: Re: PROBLEM: The --call-graph=fp data does do not agree with the --call-graph=dwarf results
Date: Thu, 8 Sep 2022 15:12:49 -0400	[thread overview]
Message-ID: <2ff91b93-0daf-afef-682a-437fcffe46f3@redhat.com> (raw)
In-Reply-To: <cb3efad5-37eb-29e4-03b0-f0bcc8be9918@redhat.com>

Hi,

Because of the previous issue of fp unwinding not including
information about inlined functions I wanted to get an idea how often
inline functions occurring in the code.  I have a simple script that
uses dwgrep to extract the number of actual functions and inlined
function then compute the average number of inlined functions for each
actual function
(https://github.com/wcohen/quality_info/blob/master/dwgrep/inlined_funcs).
I ran some quick a quick experiment a few binaries on various
architectures running Fedora to get some actual numbers.


	      average inlined functions per real function

	       architecture
binary		i386	 x86_64	    armv7    aarch64  riscv
vmlinux		-	 6.9	    3.5	     7.4      7.7
libc		1.33	 1.3	    1.3	     1.3      1.1
emacs		-	 17.3	    16.8     18.3     18.6	
stap		-	 75.9	    82.3     77.3     50.3		
libdw-0.187.so  -	 3.3	    3.7	     3.7      3.7
Xwayland	-	 3.9	    -	     3.9      -
libxul.so	-	 19.2	    -	     27.8     -

One thing to note is that for some executables like emacs and
systemtap's stap command there are a significant number of inlined
functions per function.  For stap part of this might be due to it
using C++.  With that ratio of inline functions to real function
omitting the inline functions from the backtrace information is likely
to provide an incomplete picture of what is occurring in the code.

One concern would be sampling skid for inlined functions in the
current function.  Rather than marking the sample to the instruction
that triggered the event it gets attached to another instruction for a
inlined function that doesn't have anything to do with the sample.
The triggering instructions could have been from another inlined
function or the real function everything has been inlined into.  That
might cause people to look in the wrong area of source code.  This
would only be an issue for the current function that is executing.
For the unwinding of the callers that information should be more
precise.


-Will


      parent reply	other threads:[~2022-09-08 19:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 14:21 PROBLEM: The --call-graph=fp data does do not agree with the --call-graph=dwarf results William Cohen
2022-08-31 12:17 ` Jiri Olsa
2022-08-31 13:47   ` William Cohen
2022-08-31 14:22   ` Milian Wolff
2022-08-31 16:15     ` Arnaldo Carvalho de Melo
2022-09-08 19:12 ` William Cohen [this message]

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=2ff91b93-0daf-afef-682a-437fcffe46f3@redhat.com \
    --to=wcohen@redhat.com \
    --cc=linux-perf-users@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).