Re: [External] Re: [RFC PATCH 0/2] zram: objects charge to mem_cgroup

[贺中坤 <hezhongkun.hzk@bytedance.com>]

On Fri, Jul 7, 2023 at 10:44 PM Michal Hocko <mhocko@suse.com> 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@cmpxchg.org/

>
> > 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