Re: [External] Re: [PATCH bpf-next v2 7/9] libbpf: don't free btf if program of multi-link tracing existing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux