On Fri, Jul 7, 2023 at 10:44 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > Why do we want/need that? Applications can currently escape their cgroup memory containment when zram is enabled regardless of indirect(swapfile) or direct usage(disk) . This patch adds memcg accounting to fix it. Zram and zswap have the same problem，please refer to the patch corresponding to zswap[1]. [1] https://lore.kernel.org/all/20220510152847.230957-7-hannes@xxxxxxxxxxx/ > > > summarize the previous discussion: > > [1] As I can see, Michal's concern is that the charges are going to fail > > and swapout would fail. > > > > The indirect use of zram is in the context of PF_MEMALLOC, so > > the charge must be successful. > > No, this was not my concern. Please read through that more carefully. My > concern was that the hard limit reclaim would fail. PF_MEMALLOC will not > help in that case as this is not a global reclaim path. > Sorry for my expression. I mean the hard limit reclaim would fail. As i can see, the PF_MEMALLOC is not only used in global reclaim path but the mem_cgroup reclaim. try_charge_memcg try_to_free_mem_cgroup_pages noreclaim_flag = memalloc_noreclaim_save(); nr_reclaimed = do_try_to_free_pages(zonelist, &sc); memalloc_noreclaim_restore(noreclaim_flag); > Also let's assume you allow swapout charges to succeed similar to > PF_MEMALLOC. That would mean breaching the limit in an unbounded way, > no? > -- Chage compressed page once, mean a page will be freed. the size of compressed page is less than or equal to the page to be freed. So not an unbounded way. > Michal Hocko > SUSE Labs
