Prev: pppoe: initilize pppoe_pernet before usage
Next: [PATCH] pppoe: initilize pppoe_pernet before usage
From: Ingo Molnar on 24 May 2010 03:40

* Arnaldo Carvalho de Melo <acme(a)infradead.org> wrote:

> Hi Ingo,
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6 perf
>
> Regards,
>
> - Arnaldo
>
> Arnaldo Carvalho de Melo (2):
> perf report: Support multiple events on the TUI
> perf annotate: Fix up usage of the build id cache
>
> tools/perf/builtin-report.c | 60 +++++++++++++++++++++--------------
> tools/perf/util/hist.c | 13 ++++++-
> tools/perf/util/hist.h | 14 +++++++-
> tools/perf/util/newt.c | 74 ++++++++++++++++++++++++++++++++++--------
> 4 files changed, 119 insertions(+), 42 deletions(-)

Pulled, thanks Arnaldo!

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephane Eranian on 25 May 2010 17:10
On Mon, May 24, 2010 at 3:31 AM, Arnaldo Carvalho de Melo
<acme(a)infradead.org> wrote:
> Hi Ingo,
>
>        Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6 perf
>
> Regards,
>
> - Arnaldo
>
> Arnaldo Carvalho de Melo (2):
>  perf report: Support multiple events on the TUI
>  perf annotate: Fix up usage of the build id cache
>
With these patches, can I analyze a binary on a remote
machine? If I copy perf.data + .debug subdir, then can
I run perf annotate on a different machine, where I don't
have the sampled binaries installed?

I have tried that today using -tip, and perf annotate still
looked for the binary using its original pathname in perf.data.
perf report worked fine.

Thanks.

>  tools/perf/builtin-report.c |   60 +++++++++++++++++++++--------------
>  tools/perf/util/hist.c      |   13 ++++++-
>  tools/perf/util/hist.h      |   14 +++++++-
>  tools/perf/util/newt.c      |   74 ++++++++++++++++++++++++++++++++++--------
>  4 files changed, 119 insertions(+), 42 deletions(-)
>
>



--
Stephane Eranian | EMEA Software Engineering
Google France | 38 avenue de l'Opéra | 75002 Paris
Tel : +33 (0) 1 42 68 53 00
This email may be confidential or privileged. If you received this
communication by mistake, please
don't forward it to anyone else, please erase all copies and
attachments, and please let me know that
it went to the wrong person. Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 25 May 2010 21:00
Em Tue, May 25, 2010 at 11:08:29PM +0200, Stephane Eranian escreveu:
> On Mon, May 24, 2010 at 3:31 AM, Arnaldo Carvalho de Melo <acme(a)infradead.org> wrote:
> > Arnaldo Carvalho de Melo (2):
> > �perf report: Support multiple events on the TUI
> > �perf annotate: Fix up usage of the build id cache

> With these patches, can I analyze a binary on a remote
> machine? If I copy perf.data + .debug subdir, then can
> I run perf annotate on a different machine, where I don't
> have the sampled binaries installed?

It should, either directly thru 'perf annotate foo_symbol' or via the
TUI 'perf report' browser.

> I have tried that today using -tip, and perf annotate still
> looked for the binary using its original pathname in perf.data.
> perf report worked fine.

Can you please try it with -vvvv and make the output available
somewhere?

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephane Eranian on 26 May 2010 15:10
Hi,

+lkml et al.

On Wed, May 26, 2010 at 8:23 PM, Arnaldo Carvalho de Melo
<acme(a)infradead.org> wrote:
> Em Wed, May 26, 2010 at 06:45:18PM +0200, Stephane Eranian escreveu:
>> Attached is the trace for
>> perf annotate -i ~/perf.data noploop
>>
>> I get no output at all (TUI is off). Copied over .debug tarball + perf.data.
>
> Looks like the bug I'm investigating now:
>
> build id event received for [kernel.kallsyms]: 54b1e7cc3cf52e0db255aab44ce7538eb62655b8
> build id event received for /tmp/noploop: 875ae61623e89f408b425ca0486a9ec99e3ac73e
> Looking at the vmlinux_path (5 entries long)
> No build_id in vmlinux, ignoring it
> No build_id in /boot/vmlinux, ignoring it
> No build_id in /boot/vmlinux-2.6.34-tip-default+, ignoring it
> build_id in /lib/modules/2.6.34-tip-default+/build/vmlinux is
> 3635a0e8dfc9a1afbd5627c2ba789e41d77d3cd1 while expected is
> 54b1e7cc3cf52e0db255aab44ce7538eb62655b8, ignoring it
> No build_id in /usr/lib/debug/lib/modules/2.6.34-tip-default+/vmlinux, ignoring it
>
> In my case it is not finding the vmlinux because I'm using RHEL6 Beta
> kernel without the respective kernel-debuginfo{-common} packages so it
> doesn't find the vmlinux, uses just /proc/kallsyms and that is not
> enough for annotation.
>
> In your case the problem is that we only cache the kallsyms file in the
> build-id cache ($HOME/.debug) and that is not enough for annotation, so
> I have to fix two things:
>
I can understand the issue with the kernel symbols.
But in this example, I only really care about the symbols in the
noploop program (/tmp/noploop).

Missing symbol support for the kernel should not cause perf to avoid
trying to resolve the symbols in other modules such as my user program
here.

> 1. tell about these constraints when a symbol cannot be annotated, not
> just silently fail
>
Agreed, print something like <uknown symbol> or <cannot resolve symbol>


> 2. cache the vmlinux file in the build-id cache instead of the vmlinux,
> if the vmlinux file was found, if not, fallback to caching the kallsyms
> file.
>
Don't you need to match buildid here too, the vmlinux linux on the host
may not match the one on the target, i.e., monitored system.

> Both can't be cached at the same time as they will have the same
> build-id and thus at least the symlink would be to one of them.
>
> I'll make this even configurable in ~/.perfconfig, on a new [symbol]
> section, something like:
>
> [symbol]
>
>        cache_vmlinux = on/off
>
> So that people that have issues with the size of these beasts can trade
> off disk space used by the cache versus being able to do annotation.
>
Yes, disk space is an issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 26 May 2010 15:40
Em Wed, May 26, 2010 at 09:07:05PM +0200, Stephane Eranian escreveu:
> Hi,
>
> +lkml et al.
>
> On Wed, May 26, 2010 at 8:23 PM, Arnaldo Carvalho de Melo
> <acme(a)infradead.org> wrote:
> > Em Wed, May 26, 2010 at 06:45:18PM +0200, Stephane Eranian escreveu:
> >> Attached is the trace for
> >> perf annotate -i ~/perf.data noploop
> >>
> >> I get no output at all (TUI is off). Copied over .debug tarball + perf.data.
> >
> > Looks like the bug I'm investigating now:
> >
> > build id event received for [kernel.kallsyms]: 54b1e7cc3cf52e0db255aab44ce7538eb62655b8
> > build id event received for /tmp/noploop: 875ae61623e89f408b425ca0486a9ec99e3ac73e
> > Looking at the vmlinux_path (5 entries long)
> > No build_id in vmlinux, ignoring it
> > No build_id in /boot/vmlinux, ignoring it
> > No build_id in /boot/vmlinux-2.6.34-tip-default+, ignoring it
> > build_id in /lib/modules/2.6.34-tip-default+/build/vmlinux is
> > 3635a0e8dfc9a1afbd5627c2ba789e41d77d3cd1 while expected is
> > 54b1e7cc3cf52e0db255aab44ce7538eb62655b8, ignoring it
> > No build_id in /usr/lib/debug/lib/modules/2.6.34-tip-default+/vmlinux, ignoring it
> >
> > In my case it is not finding the vmlinux because I'm using RHEL6 Beta
> > kernel without the respective kernel-debuginfo{-common} packages so it
> > doesn't find the vmlinux, uses just /proc/kallsyms and that is not
> > enough for annotation.
> >
> > In your case the problem is that we only cache the kallsyms file in the
> > build-id cache ($HOME/.debug) and that is not enough for annotation, so
> > I have to fix two things:
> >
> I can understand the issue with the kernel symbols.

That has to be fixed and I've got some patches already for that, testing
them now.

> But in this example, I only really care about the symbols in the
> noploop program (/tmp/noploop).
>
> Missing symbol support for the kernel should not cause perf to avoid
> trying to resolve the symbols in other modules such as my user program
> here.

Right, my bad, I thought that the problem was about the kernel symbols.

Then can you try replacing:

perf annotate -i ~/perf.data noploop

with:

perf annotate -i ~/perf.data -d noploop

And see if that helps?

Because, in the debug output you sent me we have:

Thread 11487 noploop
Functions:
Map: 400000-401000 0 /tmp/noploop
dso: noploop (/tmp/noploop, Functions, loaded, 875ae61623e89f408b425ca0486a9ec99e3ac73e)
508-58f _init
590-5bb _start
5bc-5df call_gmon_start
5e0-64f __do_global_dtors_aux
650-67f frame_dummy
680-681 noploop
6e0-6ea handler
6f0-6f1 __libc_csu_fini
700-788 __libc_csu_init
790-7c7 __do_global_ctors_aux
7c8-1000 _fini

So yes, there is a symbol called noploop and it is in the binary
noploop, that _has_ a build-id, and that is in the cache, perf managed
to load its symtab and knows where it is mapped, when it created this
symbol it did:

symbol__new: noploop 0x680-0x681
dso__load_sym: adjusting symbol: st_value: 0x400690 sh_addr: 0x400590 sh_offset: 0x590

Now with perf annotate -D you should get a raw dump that will tell you
if it managed to find the hist_entry for this symbol.

And I checked and there are no other "noploop" symbol in any of the
other DSOs involved.

> > 1. tell about these constraints when a symbol cannot be annotated, not
> > just silently fail
> >
> Agreed, print something like <uknown symbol> or <cannot resolve symbol>
>
>
> > 2. cache the vmlinux file in the build-id cache instead of the vmlinux,
> > if the vmlinux file was found, if not, fallback to caching the kallsyms
> > file.
> >
> Don't you need to match buildid here too, the vmlinux linux on the host
> may not match the one on the target, i.e., monitored system.

Right, it is checked if the build-id is in the perf.data file.

> > Both can't be cached at the same time as they will have the same
> > build-id and thus at least the symlink would be to one of them.
> >
> > I'll make this even configurable in ~/.perfconfig, on a new [symbol]
> > section, something like:
> >
> > [symbol]
> >
> > � � � �cache_vmlinux = on/off
> >
> > So that people that have issues with the size of these beasts can trade
> > off disk space used by the cache versus being able to do annotation.
> >
> Yes, disk space is an issue.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3
Prev: pppoe: initilize pppoe_pernet before usage
Next: [PATCH] pppoe: initilize pppoe_pernet before usage