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

Groups > linux.debian.kernel > #62427 > unrolled thread

Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd

Back to article view | Back to linux.debian.kernel

Contents

  Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd Mike Hommey <mh+reportbug@glandium.org> - 2018-10-25 08:30 +0200
    Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd Mike Hommey <mh@glandium.org> - 2018-10-25 12:20 +0200
      Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd Ben Hutchings <ben@decadent.org.uk> - 2018-10-26 02:20 +0200
        Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd "Steinar H. Gunderson" <sesse@debian.org> - 2020-08-18 01:20 +0200
    Processed: Re: Bug#911815: /usr/bin/perf_4.18: Please build perf  against libbfd "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-10-26 02:20 +0200

#62427 — Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd

Package: linux-perf-4.18
Version: 4.18.10-2
Severity: wishlist
File: /usr/bin/perf_4.18

Dear Maintainer,

Running e.g. perf report with dwarf call graph info can take a long time
depending on the size of the profile and the size of dwarf info in the
binaries being profiled. That's because each address in each library is
handled by forking and executing a new addr2line process. Each addr2line
process has to parse the dwarf info of the library it's given just to
find the location of one address. Multiply by the number of addresses,
and this can quickly become ridiculous.

Perf, however, has an alternative implementation that just uses libbfd,
so it would be much faster than spawning a large amount of new
processes, each with a large overhead.

Mike


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-perf-4.18 depends on:
ii  libbabeltrace1  1.5.6-1
ii  libc6           2.27-6
ii  libdw1          0.170-0.5
ii  libelf1         0.170-0.5
ii  liblzma5        5.2.2-1.3
ii  libnuma1        2.0.12-1
ii  libperl5.26     5.26.2-7+b1
ii  libpython3.6    3.6.7-1
ii  libslang2       2.3.2-1+b1
ii  libunwind8      1.2.1-8
ii  zlib1g          1:1.2.11.dfsg-1

Versions of packages linux-perf-4.18 recommends:
ii  linux-base  4.5

Versions of packages linux-perf-4.18 suggests:
pn  linux-doc-4.18  <none>

-- no debconf information

[toc] | [next] | [standalone]

#62428

On Thu, Oct 25, 2018 at 03:20:11PM +0900, Mike Hommey wrote:
> Package: linux-perf-4.18
> Version: 4.18.10-2
> Severity: wishlist
> File: /usr/bin/perf_4.18
> 
> Dear Maintainer,
> 
> Running e.g. perf report with dwarf call graph info can take a long time
> depending on the size of the profile and the size of dwarf info in the
> binaries being profiled. That's because each address in each library is
> handled by forking and executing a new addr2line process. Each addr2line
> process has to parse the dwarf info of the library it's given just to
> find the location of one address. Multiply by the number of addresses,
> and this can quickly become ridiculous.
> 
> Perf, however, has an alternative implementation that just uses libbfd,
> so it would be much faster than spawning a large amount of new
> processes, each with a large overhead.

I found https://salsa.debian.org/kernel-team/linux/blob/master/debian/rules.d/tools/perf/Makefile#L27-31

This sucks badly :(
I have some massive perf data that take *hours* to deal with without
libbfd. With a reduced perf data, this is the kind of difference this
makes:

$ time perf script > /dev/null   # addr2line
real    3m8.718s
user    1m12.606s
sys     1m56.649s

$ time perf script > /dev/null   # libbfd
real    0m4.141s
user    0m3.425s
sys     0m0.894s

Mike

[toc] | [prev] | [next] | [standalone]

#62431

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 wontfix

On Thu, 2018-10-25 at 18:55 +0900, Mike Hommey wrote:
[...]
> I found https://salsa.debian.org/kernel-team/linux/blob/master/debian/rules.d/tools/perf/Makefile#L27-31
[...]

For future reference, that's the comment:

# perf can link against libbfd if available, but the result is
# undistributable as they are licenced under GPL v2 and v3+
# respectively.  Override detection of libbfd and insist that
# cplus_demangle() can be found in libiberty (LGPL v2.1+).

Tagging this wontfix since we can't fix that problem.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
                                                           - Bill Gates

[toc] | [prev] | [next] | [standalone]

#67789

On Fri, Oct 26, 2018 at 01:12:51AM +0100, Ben Hutchings wrote:
> For future reference, that's the comment:
> 
> # perf can link against libbfd if available, but the result is
> # undistributable as they are licenced under GPL v2 and v3+
> # respectively.  Override detection of libbfd and insist that
> # cplus_demangle() can be found in libiberty (LGPL v2.1+).
> 
> Tagging this wontfix since we can't fix that problem.

But we can probably make the addr2line solution much faster?
perf runs:

        scnprintf(cmd, sizeof(cmd), "addr2line -e %s %016"PRIx64,
                  dso_name, addr);

        fp = popen(cmd, "r");

but the normal way of running addr2line is to run it and then start feeding
it addresses on stdin (ie. don't start the program anew for each and every
address we want to look up). I haven't tried, but it sounds like that would
reduce overhead significantly?

I also don't know if there's a cache somewhere in front of this? It seems to
look up the same addresses over and over and over again, at least in my case
(decoding a processor trace).

/* Steinar */
-- 
Homepage: https://www.sesse.net/

[toc] | [prev] | [next] | [standalone]

#62430 — Processed: Re: Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd

Processing control commands:

> tag -1 wontfix
Bug #911815 [linux-perf-4.18] /usr/bin/perf_4.18: Please build perf against libbfd
Added tag(s) wontfix.

-- 
911815: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web