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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FD86C54EBC for ; Thu, 12 Jan 2023 09:48:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234311AbjALJsG (ORCPT ); Thu, 12 Jan 2023 04:48:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239781AbjALJrS (ORCPT ); Thu, 12 Jan 2023 04:47:18 -0500 Received: from outbound-smtp21.blacknight.com (outbound-smtp21.blacknight.com [81.17.249.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8722913F21 for ; Thu, 12 Jan 2023 01:43:45 -0800 (PST) Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp21.blacknight.com (Postfix) with ESMTPS id 2874ECCCFB 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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