Re: [RFT] Testing 1.22

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Sat, May 29, 2021 at 05:40:17PM -0700, Andrii Nakryiko escreveu:
> On Fri, May 28, 2021 at 12:45 PM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > commit b579a18a1ea0ee84b90b5302f597dda2edf2f61b
> > Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> > Date:   Fri May 28 16:41:30 2021 -0300
> >
> >     pahole: Allow encoding BTF into a detached file
> >
> >     Previously the newly encoded BTF info was stored into a ELF section in
> >     the file where the DWARF info was obtained, but it is useful to just
> >     dump it into a separate file, do it.
> >
> >     Requested-by: Andrii Nakryiko <andrii@kernel.org>
> >     Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> >
> 
> Looks good, see few minor comments below. At some point it probably
> would make sense to formalize "btf_encoder" as a struct with its own
> state instead of passing in multiple variables. It would probably also

Take a look at the tmp.master branch at:

https://git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=tmp.master

that btf_elf class isn't used anymore by btf_loader, that uses only
libbpf's APIs, and now we have a btf_encoder class with all the globals,
etc, more baby steps are needed to finally ditch btf_elf altogether and
move on to the parallelization.

I'm doing 'pahole -J vmlinux && btfdiff' after each cset and doing it
very piecemeal as I'm doing will help bisecting any subtle bug this may
introduce.

> allow to parallelize BTF generation, where each CU would proceed in
> parallel generating local BTF, and then the final pass would merge and
> dedup BTFs. Currently reading and processing DWARF is the slowest part
> of the DWARF-to-BTF conversion, parallelization and maybe some other
> optimization seems like the only way to speed the process up.
> 
> Acked-by: Andrii Nakryiko <andrii@kernel.org>

Thanks!

- Arnaldo