On Mon 10-07-23 17:35:07, 贺中坤 wrote: > 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); My bad, I have overlooked this. I forgot about 89a2848381b5f. > > 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. OK, this is an important detail to mention. Also have tried to get some numbers of how much excess is happening for a mixed bag of compressible memory? -- Michal Hocko SUSE Labs
