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

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

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

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd Tony Garnock-Jones <tonyg@leastfixedpoint.com> - 2021-09-09 13:10 +0200
    Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd "Steinar H. Gunderson" <sesse@debian.org> - 2021-09-09 15:00 +0200
    Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd Tony Garnock-Jones <tonyg@leastfixedpoint.com> - 2021-09-10 12:40 +0200
      Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd Salvatore Bonaccorso <carnil@debian.org> - 2021-11-11 22:40 +0100

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

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

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

[toc] | [next] | [standalone]

#72861

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/

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

#72875

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

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

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

#73654

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

[toc] | [prev] | [standalone]

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

csiph-web