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 40181C54EBD for ; Thu, 12 Jan 2023 09:43:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA4618E0002; Thu, 12 Jan 2023 04:43:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C55938E0001; Thu, 12 Jan 2023 04:43:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B43278E0002; Thu, 12 Jan 2023 04:43:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A3EEB8E0001 for ; Thu, 12 Jan 2023 04:43:47 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7D379C0443 for ; Thu, 12 Jan 2023 09:43:47 +0000 (UTC) X-FDA: 80345660094.02.15C6E56 Received: from outbound-smtp07.blacknight.com (outbound-smtp07.blacknight.com [46.22.139.12]) by imf11.hostedemail.com (Postfix) with ESMTP id AFB8540002 for ; Thu, 12 Jan 2023 09:43:45 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.12 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673516626; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o8ucxtl5LnJ0qaUAAbYln6hKCZJ50zMENIMsdpTR0Sg=; b=xsl8supyCJr6nncAWCsnQAYp0NFqIIPHTcsirWmpkkxyws9U5JqKa54uxBZCyz5NIbIzoY n203b7FAHEkBnULs00jzehiVfrn94ARYxXxbSmRG71OlTLwqCfizZIbY5N7/YSsHv10xnl Iexs1lZHNnqCJnGxuDkJ8G94TQkvPJY= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.12 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673516626; a=rsa-sha256; cv=none; b=L0muYv9bBSwzH8S3y8bdNGZBbnYgZYWGPbZFkptVUsthyi/PG2z7pbLa4Qo3VF8zzUzvVv cwp7G+pNWLT0L+WcQGlVQI1/10FEjsmf3VAuaouWyLELzBFkA0njCzP1xd8IHEGSU7OEP6 JyAW7fB2goOQqLHUhIoZJ3dzcLlw48E= Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp07.blacknight.com (Postfix) with ESMTPS id 2580C1C3873 for ; Thu, 12 Jan 2023 09:43:44 +0000 (GMT) Received: (qmail 4654 invoked from network); 12 Jan 2023 09:43:43 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 12 Jan 2023 09:43:43 -0000 Date: Thu, 12 Jan 2023 09:43:41 +0000 From: Mel Gorman To: Michal Hocko Cc: Linux-MM , Andrew Morton , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , LKML Subject: Re: [PATCH 5/7] mm/page_alloc.c: Allow __GFP_NOFAIL requests deeper access to reserves Message-ID: <20230112094341.hom3ccscbko6v626@techsingularity.net> References: <20230109151631.24923-1-mgorman@techsingularity.net> <20230109151631.24923-6-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: AFB8540002 X-Stat-Signature: 8kddd1z3qbaaowrquojxgwojdqedqo36 X-Rspam-User: X-HE-Tag: 1673516625-611959 X-HE-Meta: U2FsdGVkX1+b8yUyAC261eom1nXCV4jv2gEIijgwImo9E7YzXfg6+cV7cqTDwzDxQatjwQ9pJqjaiKygDdw9WlygfobpJfvKohD3X3UOgWPyI2ps+9lFKXF3h3Eyo1wArYrUQibbB3aQCgdFpSE3Oj/2SCPHz1mxRN60xrRcMK29DMlqtKUxn/GVkXKo0b75r9hSjB493mGEhCUkZyCBfIN4bqEzBMiNeRG3Fo3R/JEmdCMK/F33ZEpwOhiDXIC8w/BEiKsyVNAKeugxHjB4Hwr+Mlv+CFLx2C0B+cAF22Km8Hj0j3cMQ78R5Nc/t/06MuJF8PIk53L4wTdyIl6RXzg4ZmBc7yiYvm5f6EaCDgoOQzqAJm8vv5BHGhinu4K+48MNcJ5emUEZjJQBB+0Z1gZCpi5r2a/Hq5Gal+1LnIE9SAcNDBNCu6gvhw8letwOjXuDI+WU0l+gtmBUI5Ven7srQbBsmzkW7Ju6ejhSctczA4XBz+tsqFhg4J0LuFtzGCP/5Bgf9M9Au4C7p2l99srXqpPOwopKNt1G2Lh9+jfG8/ZdVpl52Fn3OVX3XcEmDbBMHPiLKgnbC7G/Hi0+yhZk9YXdpRn6TrYGPCAW3Q6rmG/BfFjFF+5A74bcaSTb/3fZidu/wWFNX/AQ6HUvHgNlCoHs0FxXIZ5ILEXrQTc+0X1N0k0lXs0eqP3e8tZNI2oYAU89RoARYPe+2q9BttgoKzuaOt6eUDRqZDnk1g72gYMRQTM2PWu2k6b9sXqO5zit0scTmKdBb6XqoWfPGQJlgho+xBj8J3IHT3tzJuTiDizjklg35alXgQ8awoBGXYEJ7VwdUnnvDngcDHfC7XWH4F3DFCgaKrhJ/9zC5CCujvSZvho+AtTOxLjl2I5aX+WBIKMdGHd60D+aX8wpj3pNM0ofyZh1AKXyUOuuoIuZcItJY858UenmbrtUYnGH+W0EY8ArUgN9+BY9tlE Qrl3kcXK ORcJ9aKtAdOon1p3F8PKNujvAQg== 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, Jan 11, 2023 at 04:46:13PM +0100, Michal Hocko wrote: > On Mon 09-01-23 15:16:29, Mel Gorman wrote: > > Currently __GFP_NOFAIL allocations without any other flags can access 25% > > of the reserves but these requests imply that the system cannot make forward > > progress until the allocation succeeds. Allow __GFP_NOFAIL access to 75% > > of the min reserve. > > I am not sure this is really needed. IIRC the original motivation for > allowing NOFAIL request to access access to memory reserves was > GFP_NOFS|__GFP_NOFAIL requests which do not invoke the OOM killer. > The amount of memory reserves granted was not really important. The > point was to allow to move forward. Giving more of the reserves is a > double edge sword. It can help in some cases but it can also prevent > other high priority users from fwd progress. > > I would much rahter see such a change with an example where it really > made a difference. > Fair point but based on your review for "mm/page_alloc: Give GFP_ATOMIC and non-blocking allocations access to reserves" and only allowing non-blocking allocations to access reserves if __GFP_HIGH is also specified, this patch becomes a no-op and can be dropped. If GFP_NOFAIL requests really require deeper access to reserves, it'll have to be explicitly handled in __zone_watermark_ok and __GFP_NOFAIL would be added to the ALLOC_RESERVES collection of flags. -- Mel Gorman SUSE Labs