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: <20230707044707.1169285-1-hezhongkun.hzk@bytedance.com> <ZKvi4ZvhQaIFtSvg@dhcp22.suse.cz>
In-Reply-To: <ZKvi4ZvhQaIFtSvg@dhcp22.suse.cz>
From:   =?UTF-8?B?6LS65Lit5Z2k?= <hezhongkun.hzk@bytedance.com>
Date:   Mon, 10 Jul 2023 22:59:18 +0800
Message-ID: <CACSyD1M9ad6wTeT-jAtAyWz2LztLrRok8bVT56+Xbx-NReRe7g@mail.gmail.com>
Subject: Re: [External] Re: [RFC PATCH 2/2] zram: charge the compressed RAM to
 the page's memcgroup
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"
Precedence: bulk

>
> AFAICS your obj_cgroup_charge_zram doesn't have gfp argument.
>
> Anyway, memalloc_noreclaim_save is an abuse IMHO (the primary purpose of
> the flag is to prevent recursion into the memory reclaim). Do you really
> can not perform any memory recalim to trigger to free up some memory if
> the memcg is at the hard limit boundary?
>

Got it . I agree, memalloc_noreclaim_save should not be used, but return nomem
directly,which is more clear and satisfies both direct and indirect usage.