From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EE32C433EF for ; Wed, 30 Mar 2022 08:06:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD2728D0002; Wed, 30 Mar 2022 04:06:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C81D58D0001; Wed, 30 Mar 2022 04:06:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B99018D0002; Wed, 30 Mar 2022 04:06:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0215.hostedemail.com [216.40.44.215]) by kanga.kvack.org (Postfix) with ESMTP id A66718D0001 for ; Wed, 30 Mar 2022 04:06:20 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 584EF8249980 for ; Wed, 30 Mar 2022 08:06:20 +0000 (UTC) X-FDA: 79300320120.21.913EE7D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf01.hostedemail.com (Postfix) with ESMTP id CB95E4000C for ; Wed, 30 Mar 2022 08:06:19 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 7A9B221605; Wed, 30 Mar 2022 08:06:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1648627578; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Um5MncWQPFK069jInV5QbM0hF4fayUXS1W56obOkrFk=; b=gojrEkSRQEgWFK1XNxkCS3aNTUXaXPocr2R7tm2tGJZ9AYJ4wWLbcKFl9rl2BKHSSgcBp8 +RrlEZ/jEkqw3j2XXMdTPhVVwj7f4T+mJIawfsl7XKqgMUy5ZNW3PB28N/9/crLubb+OKm kUQUTXQEcU5iVDguo8N3rp2jEDU99p0= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 3F6BCA3B9B; Wed, 30 Mar 2022 08:06:18 +0000 (UTC) Date: Wed, 30 Mar 2022 10:06:17 +0200 From: Michal Hocko To: Jaewon Kim 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: References: <20220330052502.26072-1-jaewon31.kim@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220330052502.26072-1-jaewon31.kim@samsung.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: CB95E4000C X-Stat-Signature: x3ps9sf1m9aer4t8twrwy4fgrpnpx4d1 X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=gojrEkSR; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1648627579-645872 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. The failure you are seeing indicates that PF_MEMALLOC context (memory reclaim) which is allow to dip into memory reserves without any limit cannot find any memory! This is really bad and it is good to learn about that. Your description doesn't really explain why we should be ignoring that situation. Is the memory allocation failure gracefully recoverable? -- Michal Hocko SUSE Labs