Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
btf: fix slow LoadKernelSpec by making Spec.Copy lazy
LoadKernelSpec is currently very slow, on the order of tens of milliseconds. The reason for this is that we copy all ~150k types before returning the Spec to the caller. This is necessary since we don't want independent callers of LoadKernelSpec to be able to influence each other. So far we've put up with the slowness in case of features that are not used that much yet (kfuncs) or worked around it by moving APIs into the btf package where we can avoid the copy. I've made multiple attempts at fixing this problem. In no particlar order: * Have an internal non-copying API and an external copying one. Users have to make sure they only call LoadKernelSpec once since it's expensive. The problem here is that we'd still like the library internal code to use a single copy of the kernel Spec, but this is very difficult due to import cycles. * Decode raw BTF lazily instead of slurping all types into memory. This saves heap memory since we keep less inflated types around and only needs to do minimal upfront work. However, the upfront work still takes 10ish ms to complete and the decoding logic becomes much more complicated since we need to lazily apply fixups. Both Dylan and I have written implementations for this, which go into the 500-600 lines of changes. Finally, I've decided to dust of a third approach: we still parse kernel BTF eagerly but make copying a Spec lazy. This makes LoadKernelSpec basically free, at the cost of more expensive Spec.TypeByID, etc. Doing CO-RE and reading split BTF also slows down, although it probably ends up faster overall since we save a lot by not copying types. Finally, we still pin one copy of the kernel spec in memory, so FlushKernelSpec() is here to stay. It's hard to estimate how much of an issue this really is since Go's tooling for heap analysis is really poor. Signed-off-by: Lorenz Bauer <lmb@isovalent.com>
- Loading branch information
Showing
9 changed files
with
316 additions
and
136 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.