Debian Bug report logs - #911815
/usr/bin/perf_4.18: Please build perf against libbfd

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh+reportbug@glandium.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: /usr/bin/perf_4.18: Please build perf against libbfd

Date: Thu, 25 Oct 2018 15:20:11 +0900

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

Message #10 received at 911815@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: 911815@bugs.debian.org

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

Date: Thu, 25 Oct 2018 18:55:27 +0900

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

Message #15 received at 911815@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: 911815@bugs.debian.org

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

Date: Fri, 26 Oct 2018 01:12:51 +0100

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #28 received at 911815@bugs.debian.org (full text, mbox, reply):

From: "Steinar H. Gunderson" <sesse@debian.org>

To: Ben Hutchings <ben@decadent.org.uk>, 911815@bugs.debian.org

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

Date: Tue, 18 Aug 2020 00:35:53 +0200

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/

Message #33 received at 911815@bugs.debian.org (full text, mbox, reply):

From: Tony Garnock-Jones <tonyg@leastfixedpoint.com>

To: 911815@bugs.debian.org

Cc: sesse@debian.org, mh@glandium.org, ben@decadent.org.uk

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

Date: Thu, 9 Sep 2021 12:54:50 +0200

[Message part 1 (text/plain, inline)]

Dear Steinar, Ben, Mike, others:

On Tue, 18 Aug 2020 00:35:53 +0200 "Steinar H. Gunderson" 
<sesse@debian.org> wrote:
> But we can probably make the addr2line solution much faster?
> perf runs:
> [...]
> 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?

Thanks, Steinar, for your suggestion! I've written a patch against the 
non-libbfd code in perf to try it out.

It works very well. What used to take endless minutes now takes a few 
seconds.

Please find my small patch (against "apt source linux-perf-5.10") attached.

I have also started the process of submitting it upstream.

Best Regards,
  Tony

[0001-tools-perf-Use-long-running-addr2line-per-dso.patch (text/x-patch, attachment)]

Message #38 received at 911815@bugs.debian.org (full text, mbox, reply):

From: "Steinar H. Gunderson" <sesse@debian.org>

To: Tony Garnock-Jones <tonyg@leastfixedpoint.com>

Cc: 911815@bugs.debian.org, mh@glandium.org, ben@decadent.org.uk

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

Date: Thu, 9 Sep 2021 14:25:48 +0200

On Thu, Sep 09, 2021 at 12:54:50PM +0200, Tony Garnock-Jones wrote:
> Thanks, Steinar, for your suggestion! I've written a patch against the
> non-libbfd code in perf to try it out.
> 
> It works very well. What used to take endless minutes now takes a few
> seconds.

Thanks for doing this! I can confirm; I tested this on “perf report” against
a perf.data with DWARF tracebacks, with perf 5.13.4 (the same file every
time), and here are the results:

  non-bfd, without patch:  7m59s
  non-bfd, with patch:       15s
  bfd:                       15s 

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

Message #43 received at 911815@bugs.debian.org (full text, mbox, reply):

From: Tony Garnock-Jones <tonyg@leastfixedpoint.com>

To: 911815@bugs.debian.org

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

Date: Fri, 10 Sep 2021 12:27:28 +0200

[Message part 1 (text/plain, inline)]

Just to follow up again, here's an improved version of the patch that 
doesn't hand-roll quite so much socketpair/fork/exec code, reusing 
existing tools/ code instead!

Also, here's the upstream discussion of the patch on the 
linux-perf-users mailing list: 
https://lore.kernel.org/linux-perf-users/20210910102307.2055484-1-tonyg@leastfixedpoint.com/T/#u

Cheers,
  Tony

[0001-tools-perf-Use-long-running-addr2line-per-dso-v2.patch (text/x-patch, attachment)]

Message #50 received at 911815@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Tony Garnock-Jones <tonyg@leastfixedpoint.com>, 911815@bugs.debian.org

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

Date: Thu, 11 Nov 2021 22:37:53 +0100

Hi,

On Fri, Sep 10, 2021 at 12:27:28PM +0200, Tony Garnock-Jones wrote:
> Just to follow up again, here's an improved version of the patch that
> doesn't hand-roll quite so much socketpair/fork/exec code, reusing existing
> tools/ code instead!
> 
> Also, here's the upstream discussion of the patch on the linux-perf-users
> mailing list: https://lore.kernel.org/linux-perf-users/20210910102307.2055484-1-tonyg@leastfixedpoint.com/T/#u

Unless mistaken, then this has landed as
https://git.kernel.org/linus/be8ecc57f180415e8a7c1cc5620c5236be2a7e56
in mainline.

Regards,
Salvatore

Message #57 received at 911815-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 911815-close@bugs.debian.org

Subject: Bug#911815: fixed in linux 5.15.2-1~exp1

Date: Mon, 15 Nov 2021 10:00:20 +0000

Source: linux
Source-Version: 5.15.2-1~exp1
Done: Salvatore Bonaccorso <carnil@debian.org>

We believe that the bug you reported is fixed in the latest version of
linux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 911815@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Salvatore Bonaccorso <carnil@debian.org> (supplier of updated linux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sun, 14 Nov 2021 14:27:40 +0100
Source: linux
Architecture: source
Version: 5.15.2-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Changed-By: Salvatore Bonaccorso <carnil@debian.org>
Closes: 804857 911815 989285 995466 996951
Changes:
 linux (5.15.2-1~exp1) experimental; urgency=medium
 .
   * New upstream stable update:
     https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.2
 .
   [ Salvatore Bonaccorso ]
   * [rt] Update to 5.15-rt17 and reenable (Closes: #995466)
   * perf srcline: Use long-running addr2line per DSO (Closes: #911815)
   * Refresh "Export symbols needed by Android drivers"
   * [rt] Update to 5.15.2-rt19
   * Input: elantench - fix misreporting trackpoint coordinates (Closes: #989285)
   * kernel/time: Enable NO_HZ_FULL (Closes: #804857)
   * io-wq: serialize hash clear with wakeup (Closes: #996951)
 .
   [ Vincent Blut ]
   * [x86] drivers/ptp: Enable PTP_1588_CLOCK_VMW as module
   * drivers/ptp: Enable PTP_1588_CLOCK_DTE, PTP_1588_CLOCK_IDT82P33,
     PTP_1588_CLOCK_IDTCM, PTP_1588_CLOCK_OCP as modules
   * drivers/ptp, net: Enable DP83640_PHY, PTP_1588_CLOCK_INES,
     NET_PTP_CLASSIFY, NETWORK_PHY_TIMESTAMPING
Checksums-Sha1:
 74ef56708169af7f69392082f89d65ed0314f0e8 203310 linux_5.15.2-1~exp1.dsc
 8424063a5cc468f6a60698f4bbf3781e8fc97b0d 127708056 linux_5.15.2.orig.tar.xz
 63dd94abfd31a2ee4eb59368794f13af2917fcde 1288828 linux_5.15.2-1~exp1.debian.tar.xz
 f65be256d83fd350693416f7fa2328f46181bee0 6399 linux_5.15.2-1~exp1_source.buildinfo
Checksums-Sha256:
 68b5e5d809d8b9a8e4e25ae36395b4714626431c0a76e618c7e9b67d0b68bfd2 203310 linux_5.15.2-1~exp1.dsc
 ff0dbe681ebc42a17622e43ac00faa1d0854b2415a83061a0bd8dbe96f340abd 127708056 linux_5.15.2.orig.tar.xz
 6d0f2b537d07eaab1b671b0e0080c35d05bc07af2e00021b6a824a5ece0c4a49 1288828 linux_5.15.2-1~exp1.debian.tar.xz
 747c9347b6293d5b455605e3d6b1ab6209f4d0eb9020753577393006f946713f 6399 linux_5.15.2-1~exp1_source.buildinfo
Files:
 e160917005445d505d4fae102ac08f38 203310 kernel optional linux_5.15.2-1~exp1.dsc
 6021fb5a178e295058dec815553c97b3 127708056 kernel optional linux_5.15.2.orig.tar.xz
 1f6832938a55dd9139a169ef3b206cfa 1288828 kernel optional linux_5.15.2-1~exp1.debian.tar.xz
 e406edc6bb4eba0184e0f24b95ea6498 6399 kernel optional linux_5.15.2-1~exp1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmGRDz9fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk
ZWJpYW4ub3JnAAoJEAVMuPMTQ89EV/IP/3nmskw1msD2jLgm82VNHxj/b9oxCHo0
Sk9r/LzbAeg1pPOd1YYgyZup5gSOdnirxFd8bzSw6B/MUuiBrd30L1zuPTur47q4
qa446TtPEIHcbSQhETtgZCyzplFnbAS6jRKBZy2kiXuxzaXKO/5i+RKzSxicuPDD
+6M1MueKiKgt3wI310K+8mOx6XvjCP3wuMbSQQuvnQ7Ea0fbNvggRhaXgdvfZYvs
jYEtFQkw5Uhnn4D2XSp9dHBW3Rz/ib6HxTlCZzQm9M/qV6Oak+9+X2ZlgWuzOfcJ
XH6dqjIB1JcZAMs0YTKZrVtEr0a+FQVD+8NSWpTXu+FzruM3Ks9XugrcGaylmliq
LlXoogeEoKAxEimZU6zxJzF1jeDSw2bWMjVoimHE1C4M2drak4gFg+EWGMflbEWb
xqnbE1A2eN138BDuPi4DSwCmhSjaiGhVoB58vnrnQz+c1jJ9DBoyRLDelYSTGNrD
BuXyXd2/Crj472aGXr5RyoqWHNDWKF39s8m4XwEhUSsCUvJJ+aN5Cn8+PB1Yww9J
aArt4Ue1h1fJyy7o4rL2ZCX187KFwiQxqUoZ1IoXx9iim80N4dJTlhO/T38c//Oa
6K+MAAHywa4o9BRwoR2DiRP4j1yhzAxgYr66OGwv18ozSGja0wbaGuyxk1b2bGQq
/25zAYf1OKSi
=29M6
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.