Re: [RFC PATCH bpf-next 0/2] libbpf: Improve BPF load performance by selectively loading kmod BTFs

On 10/08/2026 07:20, Fuyu Zhao wrote:
> 
> 
> On 8/8/2026 6:18 AM, Andrii Nakryiko wrote:
>> On Wed, Aug 5, 2026 at 9:21 PM Fuyu Zhao <[email protected]> wrote:
>>>
>>> Currently, during BPF object loading, load_module_btfs() unconditionally
>>> iterates over all loaded kernel modules and loads their BTFs. This
>>> introduces unnecessary overhead when a BPF program only needs a specific,
>>> small subset of modules. In environments with hundreds of modules,
>>> loading all module measurably increases the loading time.
>>>
>>> This series introduces a ".kmod_btfs" ELF section, allowing BPF programs
>>> to declare the modules that need BTF loading. libbpf parses this
>>> section, collects the module names, and skips loading BTFs for any
>>> module not in the list, thereby reducing overhead. It also stops the
>>> iteration early once all declared modules are found.
>>>
>>> Usage example:
>>>
>>>   DEFINE_KMOD_BTFS(_needed_kmods) = { "bpf_testmod" };
>>>
>>> Performance impact (<skel>__open_and_load() time):
>>>
>>>   Modules loaded | Without .kmod_btfs | With .kmod_btfs | Speedup
>>>   ---------------|--------------------|-----------------|--------
>>>   1              | 35.0 ms            | 35.0 ms         | Baseline
>>>   10             | 36.5 ms            | 35.1 ms         | +3.8%
>>>   100            | 46.2 ms            | 35.9 ms         | +22.3%
>>>   300            | 65.2 ms            | 38.0 ms         | +41.7%
>>
>> First, is 30ms start up overhead really such a big deal when it comes
>> to one-time thing that sets up a bunch of BPF programs? Can you
>> elaborate on the use case you have that actually is harmed by this
>> libbpf behavior?
>>
> 
> Hi Andrii,
> 
> Thanks for the feedback, and sorry for the delayed response.
> 
> To clarify the use case, we use `sched_ext` on Android mobile platforms
> and dynamically switch schedulers for performance-sensitive scenarios,
> such as gaming workloads. The BPF programs are loaded on demand when a
> scheduler switch is required, rather than being initialized once during
> system startup. Since the scheduler switch happens on the critical path
> of user interaction, the setup latency directly affects the perceived
> responsiveness of the system.
> 
> On Android devices, the impact of `load_module_btfs()` is even more
> pronounced in our use case. In our testing, loading BTFs for all modules
> takes more than 300 ms (with 93 module BTFs), which accounts for around
> 69% of the total BPF loading time. Such a delay during the scheduler
> transition can cause visible frame drops in latency-sensitive workloads.
> 
> We also tried preloading the BPF programs. However, this does not fit
> well with our use case. Mobile devices have tighter memory constraints,
> and we avoid keeping unused BPF programs resident when they are not
> needed. Since different workloads may require different schedulers,
> preloading all possible BPF programs would introduce unnecessary memory
> overhead.
> 
> By allowing a BPF program to explicitly declare the required kernel
> modules through `.kmod_btfs`, libbpf can avoid loading unrelated module
> BTFs and significantly reduce the loading latency without increasing the
> memory footprint of inactive features.
>

the approach of having an extra section .kmod_btfs feels a bit unwieldy;
we already support kernel/module qualification in autoload section names
via

SEC("fentry/mymod:foo")
SEC("fexit/vmlinux:bar")

Couldn't you use that instead to inform selective lookup in find_kernel_btf_id()?

 
> Hope this clarifies the motivation behind this change. Thanks again for
> the feedback.
> 
> Best regards,
> Fuyu
> 
>>>
>>> Fuyu Zhao (2):
>>>   libbpf: support selective kernel module BTF loading via .kmod_btfs
>>>     section
>>>   selftests/bpf: add tests for selective kmod BTF loading
>>>
>>>  tools/lib/bpf/bpf_helpers.h                   |  14 +++
>>>  tools/lib/bpf/libbpf.c                        | 112 ++++++++++++++++++
>>>  .../selftests/bpf/prog_tests/kmod_btfs.c      |  47 ++++++++
>>>  tools/testing/selftests/bpf/progs/kmod_btfs.c |  14 +++
>>>  .../selftests/bpf/progs/kmod_btfs_mix.c       |  15 +++
>>>  .../selftests/bpf/progs/kmod_btfs_nonexist.c  |  17 +++
>>>  6 files changed, 219 insertions(+)
>>>  create mode 100644 tools/testing/selftests/bpf/prog_tests/kmod_btfs.c
>>>  create mode 100644 tools/testing/selftests/bpf/progs/kmod_btfs.c
>>>  create mode 100644 tools/testing/selftests/bpf/progs/kmod_btfs_mix.c
>>>  create mode 100644 tools/testing/selftests/bpf/progs/kmod_btfs_nonexist.c
>>>
>>> --
>>> 2.34.1
>>>
>>>
> 
>