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 39F78C433EF for ; Mon, 6 Jun 2022 19:59:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE1C06B0072; Mon, 6 Jun 2022 15:59:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B8F936B0073; Mon, 6 Jun 2022 15:59:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7EFF6B0074; Mon, 6 Jun 2022 15:59:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 95B8F6B0072 for ; Mon, 6 Jun 2022 15:59:45 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6EF2A35195 for ; Mon, 6 Jun 2022 19:59:45 +0000 (UTC) X-FDA: 79548876330.28.7F12955 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf18.hostedemail.com (Postfix) with ESMTP id 9047B1C0039 for ; Mon, 6 Jun 2022 19:59:22 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6E826B81B43; Mon, 6 Jun 2022 19:59:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA503C385A9; Mon, 6 Jun 2022 19:59:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1654545580; bh=8Qcf++OOJeh9f1j7ipBSO/FN7g7O7ymNj5NhsOYgr5k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=rSvvVLIUMvX5ajxtM38HfFvfkzKLimCNXMV6uIn+2mT+hNetxmw4UutTyVKq+/dck Fu9obaqGZxCzyl01icYc2+qoXjuAuru+XMVcDaqJyANlVaZkEL74st3sQslyyf52Lx RA4S30lF3AbS5UGS+LwnRmzSnMVIvyjTjww6q500= Date: Mon, 6 Jun 2022 12:59:39 -0700 From: Andrew Morton To: Minchan Kim Cc: Jaewon Kim , ngupta@vflare.org, senozhatsky@chromium.org, avromanov@sberdevices.ru, linux-mm@kvack.org, linux-kernel@vger.kernel.org, s.suk@samsung.com, ytk.lee@samsung.com, jaewon31.kim@gmail.com Subject: Re: [PATCH] zram_drv: add __GFP_NOMEMALLOC not to use ALLOC_NO_WATERMARKS Message-Id: <20220606125939.ae37867e43b8b8b07fa06ca7@linux-foundation.org> In-Reply-To: References: <20220603055747.11694-1-jaewon31.kim@samsung.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=rSvvVLIU; dmarc=none; spf=pass (imf18.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Stat-Signature: wc5g1fqwzo8n4ko3cufsn4knghxkrt74 X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 9047B1C0039 X-HE-Tag: 1654545562-263993 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 Mon, 6 Jun 2022 12:46:38 -0700 Minchan Kim wrote: > On Fri, Jun 03, 2022 at 02:57:47PM +0900, Jaewon Kim wrote: > > The atomic page allocation failure sometimes happened, and most of them > > seem to occur during boot time. > > > > <4>[ 59.707645] system_server: page allocation failure: order:0, mode:0xa20(GFP_ATOMIC), nodemask=(null),cpuset=foreground-boost,mems_allowed=0 > > ... > > > > > The kswapd or other reclaim contexts may not prepare enough free pages > > for too many atomic allocations occurred in short time. But zram may not > > be helpful for this atomic allocation even though zram is used to > > reclaim. > > > > To get one zs object for a specific size, zram may allocate serveral > > pages. And this can be happened on different class sizes at the same > > time. It means zram may consume more pages to reclaim only one page. > > This inefficiency may consume all free pages below watmerk min by a > > process having PF_MEMALLOC like kswapd. > > However, that's how zram has worked for a long time(allocate memory > under memory pressure) and many folks already have raised min_free_kbytes > when they use zram as swap. If we don't allow the allocation, swap out > fails easier than old, which would break existing tunes. So is there a better way of preventing this warning? Just suppress it with __GFP_NOWARN?