Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230707044613.1169103-1-hezhongkun.hzk@bytedance.com>
 <ZKfFVfZovt4PnMsy@dhcp22.suse.cz> <CACSyD1M9rSadO7xb8-H0dU2-xtrZnJMBgqEMTSHhE6M5vFgC-Q@mail.gmail.com>
 <ZKgk0HfuuxsyBBXI@dhcp22.suse.cz>
In-Reply-To: <ZKgk0HfuuxsyBBXI@dhcp22.suse.cz>
From:   =?UTF-8?B?6LS65Lit5Z2k?= <hezhongkun.hzk@bytedance.com>
Date:   Mon, 10 Jul 2023 17:35:07 +0800
Message-ID: <CACSyD1NX7sfPu2Wi1ep0gJ-wt1O8-+++321Uhw4YK1Uz4rxj-g@mail.gmail.com>
Subject: Re: [External] Re: [RFC PATCH 0/2] zram: objects charge to mem_cgroup
To:     Michal Hocko <mhocko@suse.com>
Cc:     minchan@kernel.org, senozhatsky@chromium.org, david@redhat.com,
        yosryahmed@google.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Jul 7, 2023 at 10:44=E2=80=AFPM Michal Hocko <mhocko@suse.com> wrot=
e:
>
> 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=EF=BC=8Cplease 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 fai=
l
> > 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 =3D memalloc_noreclaim_save();
     nr_reclaimed =3D 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 compress=
ed
page is less than or equal to the page to be freed. So not an unbounded way=
.

> Michal Hocko
> SUSE Labs