public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Lin Ming <ming.m.lin@intel.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Andi Kleen <andi@firstfloor.org>,
	"Huang, Ying" <ying.huang@intel.com>,
	"He, Fan F" <fan.f.he@intel.com>
Subject: Re: perf: problem of 32bit mmap call graph recording
Date: Wed, 17 Aug 2011 15:19:04 +0200	[thread overview]
Message-ID: <20110817131900.GF32132@somewhere.redhat.com> (raw)
In-Reply-To: <1313569203.4115.149.camel@minggr.sh.intel.com>

On Wed, Aug 17, 2011 at 04:20:03PM +0800, Lin Ming wrote:
> Hi all, 
> 
> On 32 bit machine, we have problem to get the usersapce call graph of
> mmap syscall.
> 
> You can reproduce it with below command on 32bit machine.
> 
> sudo perf record -f -g -e raw_syscalls:sys_enter --filter "id==192" ls
> 
> sudo perf report |less
> 
> # Events: 26 
> #
> # Overhead  Command      Shared Object  Symbol
> # ........  .......  .................  ......
> #
>    100.00%       ls  [kernel.kallsyms]  [k] syscall_trace_enter
>                  |
>                  --- syscall_trace_enter
>                      syscall_trace_entry
>                     |          
>                     |--88.46%-- __mmap  <--- only __mmap, no more userspace call stacks
>                     |          
>                      --11.54%-- 0xffffe424
> 
> 
> Kernel relies on userspace bp register to get call graph information.
> But for mmap syscall, the bp register is used to pass in the sixth
> parameter(offset).
> 
> void *mmap(void *addr, size_t length, int prot, int flags,
>                   int fd, off_t offset);
> 
> Anyway to fix this issue on 32bit machine?

Ah... Well we can't do much about that I fear :)
The only way would be to rely on dwarf informations to do the
unwind. The upside is that it would work about everywhere
even on places that don't have frame pointers, the downside
is some overhead on sample records (dump a bunch of stack every
sample) and a lot of work :)

      reply	other threads:[~2011-08-17 13:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-17  8:20 perf: problem of 32bit mmap call graph recording Lin Ming
2011-08-17 13:19 ` Frederic Weisbecker [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=20110817131900.GF32132@somewhere.redhat.com \
    --to=fweisbec@gmail.com \
    --cc=acme@infradead.org \
    --cc=andi@firstfloor.org \
    --cc=fan.f.he@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=ying.huang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox