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 9C943C5479D for ; Wed, 11 Jan 2023 15:46:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D56F8E0003; Wed, 11 Jan 2023 10:46:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 25E398E0001; Wed, 11 Jan 2023 10:46:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1265B8E0003; Wed, 11 Jan 2023 10:46:19 -0500 (EST) 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 F29088E0001 for ; Wed, 11 Jan 2023 10:46:18 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 591E18059E for ; Wed, 11 Jan 2023 15:46:18 +0000 (UTC) X-FDA: 80342944836.12.9B694B4 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf29.hostedemail.com (Postfix) with ESMTP id 5B70B12000A for ; Wed, 11 Jan 2023 15:46:16 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ezLduFnd; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673451976; 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:dkim-signature; bh=eGle1qDaVLgCmc/KzANyHq27FrunNJVqz61yvg3H7TM=; b=8cZDGUFBEuf03sPgaB3x2jVd7HdDCDvPEk69RdmkgRUO2bzMkOW1OJUUXJEklOmME8WttY W8a1kQFuJYTZ0zyBLrk0Cfp+P6FESQTPfp+Cws9H3hye3jrAz2pDaxtXrM91ieLFeDgHuY VlyzetevTwqXaZF4jU2ADhDJQ0OY8zI= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ezLduFnd; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673451976; a=rsa-sha256; cv=none; b=sTx3rIYm6dU+/fgwdrmp+MYg3C+W2e9QAjJ7pfIWZEZ+Cc8dh3GQ9c2N7Q2Vem3S2lNwHy unj+BEhoR8XBLSRoZTaqD8Y5bnZbFzALO38yQ0V2KbPzQMdqM2y7UV/6GsGg7/HHFfegr5 GVJ329p5LKgx8Kk6WiM0gGk3nBKGS7o= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id BA3006017A; Wed, 11 Jan 2023 15:46:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1673451974; 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=eGle1qDaVLgCmc/KzANyHq27FrunNJVqz61yvg3H7TM=; b=ezLduFndFN+PyJnkiyV0RCMWop/miUrrWZlSQSn9lbKQ7RPAZcw3SikHtm1D3clqUPSFtV XNEmVWAQCgQ1UhW66B5NYVglF35FSjWgyFptyR2WQNEyzkKEHfFyBwT4vWVQgCTnRBhIBC JnbQz1+NiRifLjPFyJVvWFrnTjLbMMU= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 9B57E1358A; Wed, 11 Jan 2023 15:46:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 6CiJI8bZvmNDPQAAMHmgww (envelope-from ); Wed, 11 Jan 2023 15:46:14 +0000 Date: Wed, 11 Jan 2023 16:46:13 +0100 From: Michal Hocko To: Mel Gorman 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: References: <20230109151631.24923-1-mgorman@techsingularity.net> <20230109151631.24923-6-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230109151631.24923-6-mgorman@techsingularity.net> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5B70B12000A X-Stat-Signature: zfxji9tdnhy3uixsnce7kwwenewi44yh X-HE-Tag: 1673451976-452555 X-HE-Meta: U2FsdGVkX1+7aqFI9XrboXmPiKwun1qhb0BscC0wQhYoRr/EdqAnibLRqtriR07mWAR4X/gSBsKc6aRI8COyw0ocWFQ9AsQcnBoyB45C1If+CcbAKsQ47BUxAun80pNvF01Pzrwc9yoBLx35BztKR9vmrjaAX4YvpRe/ZeMKDoQ9AC9WxzkODJXU+YVoa0TBgh1VviplWcIdLKt923Hwv7n2Wfdj+hWkcGSm/s6dwyt/J1kRLmH+QKLohaglLMaO4K3uUnLlETZr35LxhEGqhFqeNjfj572Klw7Mum54XiPgKOO5IE71TYNndS6kcEvbekT8heqlUUIpRt/lv0WOTinAjI0ZHozGrBtuXbcXKCZDZO8a4lLk786+hFspoAmxHdWb2jTftooK8MEJ6ZymoBoEYY4hfWqZtBNy5XIa2UbaIo1+7s5OrfTOo+S0oJjqSWQJi3Bknxn+80WZoEUG3JW2frnFFkhQd34zHgAEqqtW2SeVsYxXSGeJZVjz3pxXtH+v2fEy/UHVCz4sEu6TSProuVFqWyDi/uf4q6htfDPhVqTLgeDXVsz5e5CIPtP1eUJJW+/JkcEZ8a69NDerwhs7pYFiPrWI37y6wjRryCMAkHmWiUae5GWGHKi/Ka/nWXhZ8qjrII2yM6EfyFKPzSfZ8Hw/6wrECGOuiN06g9OiaS7AH5ZK/igzVzMuHmfleAw7w9O+aBQIbU9iZbq2ouKZ9OGTkSo8/UETzbnlV/qMPsQeGkO9SUXUWMrrm2j+TlxDNVFaxfuHCR1sH8qfV+3ggRc6C3gJQK0uajB8MY4u+03xHZ+CCDmSWTMrSVO948cQiRlZdnEHRb6m/U4lUBSB61Y4ewtOcBsl7YdlfrdrF6qU4C0mrSqpPjQpLuQEfiA2CrxLFjiAT4iuk7YePbw29N4IDCJjLQRNgbiv2pqTrTSX5ZiB7PgtDvCdsbU96K+qx5n5ix0WfYevj3g VcGa9bjW ATmSLn+0jeEOcDjQ= 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 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. > Signed-off-by: Mel Gorman > --- > mm/page_alloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 6f41b84a97ac..d2df78f5baa2 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5308,7 +5308,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > * could deplete whole memory reserves which would just make > * the situation worse > */ > - page = __alloc_pages_cpuset_fallback(gfp_mask, order, ALLOC_HARDER, ac); > + page = __alloc_pages_cpuset_fallback(gfp_mask, order, ALLOC_MIN_RESERVE|ALLOC_HARDER, ac); > if (page) > goto got_pg; > > -- > 2.35.3 -- Michal Hocko SUSE Labs