On Tue, Mar 12, 2024 at 10:13 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Mon, Mar 11, 2024 at 7:05 PM 梦龙董 <dongmenglong.8@xxxxxxxxxxxxx> wrote: > > > > > > > > > > +LIBBPF_API void bpf_object__free_btfs(struct bpf_object *obj); > > > > + > > > > > > It shouldn't be exported. > > > libbpf should clean it up when bpf_object is freed. > > > > Yes, libbpf will clean up the btfs when bpf_object is freed in > > this commit. And I'm trying to offer a way to early free the btfs > > by the users manual to reduce the memory usage. Or, the > > btfs that we opened will keep existing until we close the > > bpf_object. > > > > This is optional, I can remove it if you prefer. > > Let's not extend libbpf api unless we really need to. > bpf_program__attach_trace_multi_opts() and > *skel*__attach() can probably free them. That's a good idea! Should we add a "bool free_btf" field to struct bpf_trace_multi_opts? bpf_program__attach_trace_multi_opts() can be called multi times for a bpf_object, which has multi bpf program of type tracing multi-link. Or, can we free the btfs automatically if we found all tracing multi-link programs are attached? Thanks! Menglong Dong > I don't see a use case where you'd want to keep them afterwards.
