Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <CGME20220330052214epcas1p250cff6b3168a1c9c253e1fe70e68ca8b@epcas1p2.samsung.com>
 <20220330052502.26072-1-jaewon31.kim@samsung.com> <YkQPefdRc+hxIXEV@dhcp22.suse.cz>
 <YkQZi5WFAwbqWKNZ@dhcp22.suse.cz>
In-Reply-To: <YkQZi5WFAwbqWKNZ@dhcp22.suse.cz>
From:   Jaewon Kim <jaewon31.kim@gmail.com>
Date:   Wed, 30 Mar 2022 18:11:46 +0900
Message-ID: <CAJrd-Ushm_t6voCEuTpx=Y9cms2QsRPvjkO-JAdLcwcedZ3k-A@mail.gmail.com>
Subject: Re: [PATCH] zram_drv: add __GFP_NOWARN flag on call to zs_malloc
To:     Michal Hocko <mhocko@suse.com>
Cc:     Jaewon Kim <jaewon31.kim@samsung.com>, minchan@kernel.org,
        ngupta@vflare.org, senozhatsky@chromium.org,
        Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, s.suk@samsung.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

2022=EB=85=84 3=EC=9B=94 30=EC=9D=BC (=EC=88=98) =EC=98=A4=ED=9B=84 5:49, M=
ichal Hocko <mhocko@suse.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
>
> 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.

Thank you for reply

Yes it was kswapd with PF_MEMALLOC, but I thought this zs_malloc could
fail on direct reclaim context.

I think zram is gracefully handling this ENOMEM situation, it actually
accounts the failed count as zram stats.
The failed page will be tried to swap out again later.

Yes I need to look into more about this memory shortage.
But I thought there were too many ALLOC_HADER requests in a short
time, and I want to see other
allocation failure logs like one with GFP_ATOMIC instead of this
zs_malloc failure log.

> --
> Michal Hocko
> SUSE Labs