Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Shakeel Butt <shakeelb@google.com>]

CCing Yosry, Muchun & Johannes

On Tue, Jul 12, 2022 at 2:52 AM Michal Hocko <mhocko@suse.com> wrote:
>
> On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> > On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@suse.com> wrote:
> [...]
> > > > Roman already sent reparenting fix:
> > > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@linux.dev/
> > >
> > > Reparenting is nice but not a silver bullet. Consider a shallow
> > > hierarchy where the charging happens in the first level under the root
> > > memcg. Reparenting to the root is just pushing everything under the
> > > system resources category.
> > >
> >
> > Agreed. That's why I don't like reparenting.
> > Reparenting just reparent the charged pages and then redirect the new
> > charge, but can't reparents the 'limit' of the original memcg.
> > So it is a risk if the original memcg is still being charged. We have
> > to forbid the destruction of the original memcg.
>
> yes, I was toying with an idea like that. I guess we really want a
> measure to keep cgroups around if they are bound to a resource which is
> sticky itself. I am not sure how many other resources like BPF (aka
> module like) we already do charge for memcg but considering the
> potential memory consumption just reparenting will not help in general
> case I am afraid.

Another very obvious example is the filesystem shared between multiple
jobs. We had a similar discussion [1] on LRU reparenting patch series.

For this use-case internally we have a memcg= mount option where the
given memcg is the common ancestor (think of pod in k8s environment)
of the jobs who are sharing the filesystem.

[1] https://lore.kernel.org/all/20210330101531.82752-1-songmuchun@bytedance.com/