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

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

 



On Tue 12-07-22 16:39:48, Yafang Shao wrote:
> On Tue, Jul 12, 2022 at 3:40 PM Michal Hocko <mhocko@xxxxxxxx> wrote:
[...]
> > > Roman already sent reparenting fix:
> > > https://patchwork.kernel.org/project/netdevbpf/patch/20220711162827.184743-1-roman.gushchin@xxxxxxxxx/
> >
> > 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.
-- 
Michal Hocko
SUSE Labs




[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