Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Wed, 30 Mar 2022 10:49:15 +0200
From:   Michal Hocko <mhocko@suse.com>
To:     Jaewon Kim <jaewon31.kim@samsung.com>
Cc:     minchan@kernel.org, ngupta@vflare.org, senozhatsky@chromium.org,
        akpm@linux-foundation.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, s.suk@samsung.com,
        jaewon31.kim@gmail.com
Subject: Re: [PATCH] zram_drv: add __GFP_NOWARN flag on call to zs_malloc
Message-ID: <YkQZi5WFAwbqWKNZ@dhcp22.suse.cz>
References: <CGME20220330052214epcas1p250cff6b3168a1c9c253e1fe70e68ca8b@epcas1p2.samsung.com>
 <20220330052502.26072-1-jaewon31.kim@samsung.com>
 <YkQPefdRc+hxIXEV@dhcp22.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YkQPefdRc+hxIXEV@dhcp22.suse.cz>
Precedence: bulk

On Wed 30-03-22 10:06:18, Michal Hocko wrote:
> On Wed 30-03-22 14:25:02, Jaewon Kim wrote:
> > The page allocation with GFP_NOIO may fail. And zram can handle this
> > allocation failure. We do not need to print log for this.
> 
> GFP_NOIO doesn't have any special meaning wrt to failures. zram
> allocates from the memory reclaim context which is a bad design IMHO.

Btw. I forgot to mention that GFP_NOIO doesn't have any different
meaning than GFP_KERNEL from this (PF_MEMALLOC) allocation context
because this request will never perform a reclaim.
-- 
Michal Hocko
SUSE Labs