Re: [PATCH bpf-next 0/5] bpf, mm: introduce cgroup.memory=nobpf

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

 



On Thu, Feb 9, 2023 at 4:54 AM Roman Gushchin <roman.gushchin@xxxxxxxxx> wrote:
>
> On Sun, Feb 05, 2023 at 06:58:00AM +0000, Yafang Shao wrote:
> > The bpf memory accouting has some known problems in contianer
> > environment,
> >
> > - The container memory usage is not consistent if there's pinned bpf
> >   program
> >   After the container restart, the leftover bpf programs won't account
> >   to the new generation, so the memory usage of the container is not
> >   consistent. This issue can be resolved by introducing selectable
> >   memcg, but we don't have an agreement on the solution yet. See also
> >   the discussions at https://lwn.net/Articles/905150/ .
> >
> > - The leftover non-preallocated bpf map can't be limited
> >   The leftover bpf map will be reparented, and thus it will be limited by
> >   the parent, rather than the container itself. Furthermore, if the
> >   parent is destroyed, it be will limited by its parent's parent, and so
> >   on. It can also be resolved by introducing selectable memcg.
> >
> > - The memory dynamically allocated in bpf prog is charged into root memcg
> >   only
> >   Nowdays the bpf prog can dynamically allocate memory, for example via
> >   bpf_obj_new(), but it only allocate from the global bpf_mem_alloc
> >   pool, so it will charge into root memcg only. That needs to be
> >   addressed by a new proposal.
> >
> > So let's give the user an option to disable bpf memory accouting.
> >
> > The idea of "cgroup.memory=nobpf" is originally by Tejun[1].
> >
> > [1]. https://lwn.net/ml/linux-mm/YxjOawzlgE458ezL@xxxxxxxxxxxxxxx/
> >
> > Yafang Shao (5):
> >   mm: memcontrol: add new kernel parameter cgroup.memory=nobpf
> >   bpf: use bpf_map_kvcalloc in bpf_local_storage
> >   bpf: introduce bpf_memcg_flags()
> >   bpf: allow to disable bpf map memory accounting
> >   bpf: allow to disable bpf prog memory accounting
>
> Hello Yafang!
>
> Overall the patch looks good to me, please, feel free to add
> Acked-by: Roman Gushchin <roman.gushchin@xxxxxxxxx>
>
> I'd squash patch (3) into (4), but up to you.
>

Sure. Will do it.

-- 
Regards
Yafang




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux