Message ID | 20250122062332.577009-1-irogers@google.com (mailing list archive) |
---|---|
Headers | show |
Series | Support dynamic opening of capstone/llvm remove BUILD_NONDISTRO | expand |
On Tue, Jan 21, 2025 at 10:23:15PM -0800, Ian Rogers wrote: > Linking against libcapstone and libLLVM can be a significant increase > in dependencies and size of memory footprint. For something like `perf > record` the disassembler and addr2line functionality won't be > used. Support dynamically loading these libraries using dlopen and > then calling the appropriate functions found using dlsym. It's unclear to me what this actually fixes. If the code is not used it should not be faulted in and the dynamic linker is lazy too, so if it's not used, it won't even be linked. I don't see any numbers, but it won't surprise me if it improved actual run time or memory usage significantly. -Andi
On Wed, Jan 22, 2025 at 7:21 AM Andi Kleen <ak@linux.intel.com> wrote: > > On Tue, Jan 21, 2025 at 10:23:15PM -0800, Ian Rogers wrote: > > Linking against libcapstone and libLLVM can be a significant increase > > in dependencies and size of memory footprint. For something like `perf > > record` the disassembler and addr2line functionality won't be > > used. Support dynamically loading these libraries using dlopen and > > then calling the appropriate functions found using dlsym. > > It's unclear to me what this actually fixes. If the code is not used > it should not be faulted in and the dynamic linker is lazy too, so > if it's not used, it won't even be linked. > > I don't see any numbers, but it won't surprise me if it improved > actual run time or memory usage significantly. In certain scenarios, like data centers, it can be useful to statically link all your dependencies to avoid dll hell. The X86 disassembler alone in libllvm is of a size comparable to the perf tool - I think this speaks to us doing a reasonably good job of size optimization of the events/metrics in the perf tool. We want these dependencies for the performance over forking objdump and addr2line, but we don't want it baked in - unless the person doing the build wants this and this is still the default if the libraries are detected by Makefile.config. Using dlopen also means distributions can have a perf tool that doesn't drag in libLLVM.so and a universe of dependencies, but when it is installed get the performance advantages. In data centres having fast disassembly/addr2line is less of a priority over the binary size cost replicated over 10,000s of machines because those machines don't tend to be running the annotate/report commands. Fwiw, Namhyung's uftrace is doing something similar for python: https://github.com/namhyung/uftrace/blob/master/utils/script-python.c#L139 and I wish the perf tool were also doing this. I think it is much nicer to have the tool fail at runtime because of a missing dependency which you can then install should you want it, rather than doing an equivalent within the code base with #ifdefs and needing users to recompile. This patch series significantly reduces the #ifdefs in places like the core disasm code. Thanks, Ian