Em Tue, Jun 08, 2021 at 09:59:48AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Mon, Jun 07, 2021 at 05:53:59PM -0700, Andrii Nakryiko escreveu: > > I think it's very fragile and it will be easy to get > > broken/invalid/incomplete BTF. Yonghong already brought up the case > I thought about that as it would be almost like the compiler generating > BTF, but you are right, the vmlinux prep process is a complex beast and > probably it is best to go with the second approach I outlined and you > agreed to be less fragile, so I'll go with that, thanks for your > comments. So, just to write some notes here from what I saw so far: 1. In the LTO cases there are inter-CU references, so the current code combines all CUs into one and we end up not being able to parallelize much. LTO is expensive, so... I'll leave it for later, but yeah, I don't think the current algorithm is ideal, can be improved. 2. The case where there's no inter CU refs, which so far is the most common, seems easier, we create N threads, all sharing the dwarf_loader state and the btf_encoder, as-is now. we can process one CU per thread, and as soon as we finish it, just grab a lock and call btf_encoder__encode_cu() with the just produced CU data structures (tags, types, functions, variables, etc), consume them and delete the CU. So each thread will consume one CU, push it to the 'struct btf' class as-is now and then ask for the next CU, using the dwarf_loader state, still under that lock, then go back to processing dwarf tags, then lock, btf add types, rinse, repeat. The ordering will be different than what we have now, as some smaller CUs (object files with debug) will be processed faster so will get its btf encoding slot faster, but that, at btf__dedup() time shouldn't make a difference, right? I think I'm done with refactoring the btf_encoder code, which should be by now a thin layer on top of the excellent libbpf BTF API, just getting what the previous loader (DWARF) produced and feeding libbpf. I thought about fancy thread pools, etc, researching some pre-existing thing or doing some kthread + workqueue lifting from the kernel but will instead start with the most spartan code, we can improve later. There it is, dumped my thoughts on this, time to go do some coding before I get preempted... - Arnaldo > - Arnaldo > > > for static variables. There might be some other issues that exist > > today, or we might run into when we further extend BTF. Like some > > custom linker script that will do something to vmlinux.o that we won't > > know about. > > > > And also this will be purely vmlinux-specific approach relying on > > extra and custom Kbuild integration. > > > > While if you parallelize DWARF loading and BTF generation, that will > > be more reliably correct (modulo any bugs of course) and will work for > > any DWARF-to-BTF cases that might come up in the future. > > > > So I wouldn't even bother with individual .o's, tbh. > > > > > > > > If this isn't the case, we can process vmlinux as is today and go on > > > creating N threads and feeding each with a DW_TAG_compile_unit > > > "container", i.e. each thread would consume all the tags below each > > > DW_TAG_compile_unit and produce a foo.BTF file that in the end would be > > > combined and deduped by libbpf. > > > > > > Doing it as my first sketch above would take advantage of locality of > > > reference, i.e. the DWARF data would be freshly produced and in the > > > cache hierarchy when we first encode BTF, later, when doing the > > > combine+dedup we wouldn't be touching the more voluminous DWARF data. > > > > Yep, that's what I'd do. > > > > > > > > - Arnaldo > > > > > > > confident about BTF encoding part: dump each CU into its own BTF, use > > > > btf__add_type() to merge multiple BTFs together. Just need to re-map > > > > IDs (libbpf internally has API to visit each field that contains > > > > type_id, it's well-defined enough to expose that as a public API, if > > > > necessary). Then final btf_dedup(). > > > > > > > But the DWARF loading and parsing part is almost a black box to me, so > > > > I'm not sure how much work it would involve. > > > > > > > > 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@xxxxxxxxxx> > > > > > > > > Thanks! > > -- > > - Arnaldo -- - Arnaldo
