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>
In-Reply-To: <ZKfFVfZovt4PnMsy@dhcp22.suse.cz>
From:   =?UTF-8?B?6LS65Lit5Z2k?= <hezhongkun.hzk@bytedance.com>
Date:   Fri, 7 Jul 2023 22:25:48 +0800
Message-ID: <CACSyD1M9rSadO7xb8-H0dU2-xtrZnJMBgqEMTSHhE6M5vFgC-Q@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

> Please state the objective you are trying to achieve by this patchset.
> It is always good to summarize the previous discussion and mention what
> is done differently or how previous review feedback has been addressed
> but the overall idea/purpose should be always explicit.
>
> Please elaborate more about both.
>

Thanks for your reply.
objective=EF=BC=9A
the compressed memory of zram charge to the cgroup of the user.

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.

[2] David's concern is that if there is a page in the BIO that is not charg=
ed,
we can not charge the compressed page for the fs->zram and whether
the recompress case is charged.

In the new solution, the recompress case can be charged. But if there is
a BIO not charged, I'm not so sure, to be honest.it would be great if
someone with more FS->BIO experience could comment.
I have to review the relevant code to check it.

[3] Yosry's concern is that the previous patchsets are very complicated,
and do not have wirteback support in zram.

For the new patchset, charging becomes very simple, and zram supports
writing back to disk.At the same time, I am hoping the use of zswap
without a backing swapfile can be enabled.

To summarize the new patchset:
We charge compressed memory directly in the zram module instead of in
the zsmalloc module because zsmallc may be used by zswap, zswap objects
has been charged once in the zswap module, so zsmallc will double charge.