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;
Date:   Fri, 7 Jul 2023 16:44:32 +0200
From:   Michal Hocko <mhocko@suse.com>
To:     =?utf-8?B?6LS65Lit5Z2k?= <hezhongkun.hzk@bytedance.com>
Cc:     minchan@kernel.org, senozhatsky@chromium.org, david@redhat.com,
        yosryahmed@google.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Subject: Re: [External] Re: [RFC PATCH 0/2] zram: objects charge to mem_cgroup
Message-ID: <ZKgk0HfuuxsyBBXI@dhcp22.suse.cz>
References: <20230707044613.1169103-1-hezhongkun.hzk@bytedance.com>
 <ZKfFVfZovt4PnMsy@dhcp22.suse.cz>
 <CACSyD1M9rSadO7xb8-H0dU2-xtrZnJMBgqEMTSHhE6M5vFgC-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACSyD1M9rSadO7xb8-H0dU2-xtrZnJMBgqEMTSHhE6M5vFgC-Q@mail.gmail.com>
Precedence: bulk

On Fri 07-07-23 22:25:48, 贺中坤 wrote:
> > 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：
> the compressed memory of zram charge to the cgroup of the user.

Why do we want/need that?

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

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?
-- 
Michal Hocko
SUSE Labs