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 C747CC433EF for ; Tue, 7 Jun 2022 23:47:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2467B6B0071; Tue, 7 Jun 2022 19:47:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F44B6B0072; Tue, 7 Jun 2022 19:47:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0BE1D6B0073; Tue, 7 Jun 2022 19:47:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EA8E56B0071 for ; Tue, 7 Jun 2022 19:47:08 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B990F347FF for ; Tue, 7 Jun 2022 23:47:08 +0000 (UTC) X-FDA: 79553078136.09.B3A6878 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by imf14.hostedemail.com (Postfix) with ESMTP id 61C49100040 for ; Tue, 7 Jun 2022 23:47:08 +0000 (UTC) Received: by mail-pf1-f182.google.com with SMTP id x4so8290167pfj.10 for ; Tue, 07 Jun 2022 16:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=xTyvpi/CRKA0ZDhB9x52q5aVKrqnKx4HjDRfGU8RMEU=; b=RhcM6qukhvT8pJFmYD+0mUKD5iWzoF5VN8gC6Tr64XQE9Mc990RPHwCJQ0Dm1TSHI0 i1v5/nMeNtJ1sTNx1X7feZVKvVM5xc0KoNGrVgd1zw8v4hbfe/d0GGgnCXp1bs9Y7bAp be+uXA+qs+u8UtQA4YdSBnqz0QTFsgOYFdcga1jqfz+kB6kD/rOTYDVi26HQl34C78QT Qv69mncqMNaEwY0ZGEKC9iwgAgq183dsWPEvWtReoG8K9jb/DSKXwrHWzZYk0vvl3TLJ avoyFNORUPpA1Q+9WfNI8gKy42nVJVfPH8LoaAbm4wZXMGYIWrr0q6q9PhVJkKn894/t JW6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=xTyvpi/CRKA0ZDhB9x52q5aVKrqnKx4HjDRfGU8RMEU=; b=uxRA9zDSvcPUvRfZEXmngR87ohP5kf4qG/rcyZ7bSlgCtkzXB2TieQLNKpS5VHIkX7 kwFeimkbrrqlNQLCMy4ESbHbHI+CGPtsxg+DUoKZ55mh3cvfqMR1dX0aiLwqT6rDab8o itGMKtVhj6uTSLWT+ZkkOvcUHpyxH8+QqGOrFH6kuYHicUcRIDv65NA9oSQn9S97cemA 9KBvnYQGGUzIz3ufK+XeTQfXXT2YHhzUyl2Hlpdr/66CHtkV0dcIkIx1oVxJBAtY1Im2 qASEKrC+Ho58VDl7YP8JwM/jnaxyVKrAmcpyRlO639eqynT5RJqDgAw0Scb50i1QuHiD EFAg== X-Gm-Message-State: AOAM530dtMxVNjB2Z9QS0DvIOxDYWeuCZ0oeEchblgeHVpDubtXKy/Ao q3Im2EL961kMDpJg4lGc0cE= X-Google-Smtp-Source: ABdhPJwXmky3Mb1g3joIbwT3sQR3nWxYKsMw1MQpZUNSfpVt5QUFs23oawRfNxy+Mb0Yfh8FKDB5bA== X-Received: by 2002:a05:6a00:1513:b0:51c:3ca8:47a4 with SMTP id q19-20020a056a00151300b0051c3ca847a4mr5537879pfu.48.1654645627188; Tue, 07 Jun 2022 16:47:07 -0700 (PDT) Received: from google.com ([2620:15c:211:201:f30f:4d03:66e6:b121]) by smtp.gmail.com with ESMTPSA id q6-20020a170902a3c600b0016203a92865sm7365536plb.107.2022.06.07.16.47.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 16:47:06 -0700 (PDT) Date: Tue, 7 Jun 2022 16:47:04 -0700 From: Minchan Kim To: Jaewon Kim Cc: Andrew Morton , "ngupta@vflare.org" , "senozhatsky@chromium.org" , "avromanov@sberdevices.ru" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Sooyong Suk , YongTaek Lee , "jaewon31.kim@gmail.com" , Chulmin Kim Subject: Re: [PATCH] zram_drv: add __GFP_NOMEMALLOC not to use ALLOC_NO_WATERMARKS Message-ID: References: <20220603055747.11694-1-jaewon31.kim@samsung.com> <20220606125939.ae37867e43b8b8b07fa06ca7@linux-foundation.org> <20220607011702epcms1p10100c4e86e2e0334f7fabbfafa3a0698@epcms1p1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220607011702epcms1p10100c4e86e2e0334f7fabbfafa3a0698@epcms1p1> Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=RhcM6quk; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf14.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.210.182 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 61C49100040 X-Rspam-User: X-Stat-Signature: sszzc7jz8byn9kex38hx5dk1tzr4td5y X-HE-Tag: 1654645628-156557 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: Hi Jaewon, On Tue, Jun 07, 2022 at 10:17:02AM +0900, Jaewon Kim wrote: > > > > > >--------- Original Message --------- > >Sender : Minchan Kim > >Date : 2022-06-07 05:48 (GMT+9) > >Title : Re: [PATCH] zram_drv: add __GFP_NOMEMALLOC not to use ALLOC_NO_WATERMARKS > > > >On Mon, Jun 06, 2022 at 12:59:39PM -0700, Andrew Morton wrote: > >> 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. > > > Hello. > > Yes correct. We may need to tune again to swap out as much as we did. > > But on my experiment, there were quite many zram allocations which might > be failed unless it has the ALLOC_NO_WATERMARKS. I thought the zram > allocations seem to be easy to affect atomic allocation failure. I understand your concern but solution here would affect to existing common users too much. > > >> > >> So is there a better way of preventing this warning? Just suppress it > >> with __GFP_NOWARN? > > > >For me, I usually tries to remove GFP_ATOMIC alllocation since the > >atomic allocation can be failed easily(zram is not only source for > >it). Otherwise, increase min_free_kbytes? > > > > I also hope driver developers to handle this atomic allocation failure. > However this selinux stuff, context_struct_to_string, is out of their domain. > Do I need to report this to selinux community? Actualy I got several > different callpaths to reach this context_struct_to_string. I am not famliar with selinux stuff but if it's common to see the GFP_ATOMIC failures in the path, I think it should have __GFP_NOWARN or other solution to allocate memory in advance. (BTW, I had similar problem before and fixed it with adding __GFP_NOWARN 648f2c6100cf, selinux: use __GFP_NOWARN with GFP_NOWAIT in the AVC) > > Yes we may need to increase min_free_kbytes. But I have an experience where > changing wmark_min from 4MB to 8MB did not work last year. Could you share > some advice about size? I don't think we could have universal golden value for it since every workload and configuration are different in their system. Maybe, your zram size is rather big compared to system memory and swappiness is rather high for boot.