Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp985911rwb; Tue, 29 Nov 2022 07:39:05 -0800 (PST) X-Google-Smtp-Source: AA0mqf6D7UPpSgBJgOa2pRBR0ABD9uqBet0E+nnnkO2CuVt9EmePAPIFatDMAAmBDQUjLGQCk1EL X-Received: by 2002:a17:90b:1942:b0:219:42d8:bd3a with SMTP id nk2-20020a17090b194200b0021942d8bd3amr7815787pjb.177.1669736344913; Tue, 29 Nov 2022 07:39:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669736344; cv=none; d=google.com; s=arc-20160816; b=HQ9DKnKnbZvdoKmT+gW/b0DQHZHeJv9Pv0YoB4c6ewARNfEW7h0Jf6ntjg8++m2dGh 4zodh6GiBBOPRNsohDmbtK6MzqmKQe0yWmO5TSaTT+uM2FiDNahSUS0uQemQ/N5F/k60 Wl1mFSB5XrmTo7eGZf3xpVwDfsHGE4DpoSKuQoaCm04IiCMRPL6Xo8QOSVOJrVucPYFx giMew8wU6FGjVTfZ92ewU5SiG7JPme1PJt0M86H90FPfvqGPXCvnGXFQ84n1DClj0S6e 4mltYVo9yk5AWx1w2l3Jj8mL5PafvN55R88OYqNu0+M+JVXM2uxVxFKwZaD/L+WPKEts eOkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=6aG26MM7VZbzZxAxq6nZIKz4NQXQI+yGR47DbM3N59I=; b=wH5rO1jqZP6OS0ee68iIeKRu9vyEOTaC44GQmLoTZm/RChpxBxtJpM4wnoDfR1qVS9 zco5lgaew3lh9bwd32l7dVjzizQxK2lcEMz+BL2XFw+0wI9yQVqsBZUIs4iSy+r/4LgH VzpLK4BbBT6xd55fDSxVUAkCdlaXRUbvx28WlE+malc8XsRUQqqFDRwrmqO3sS/Trjd8 yTYVf1T+q+JmcFd6FTBYZMJJcsNfOErpQIornT9/d8DhSDuiRf/NA1Q778CBGe0Uzfs0 fGMcshlBBhmzNuWUdX8DtnQZjnpMfQkT2r2IUPCtjZOa1Y163J9+QAuTLAg7MIH9YaXX f32Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 76-20020a62154f000000b0056b86567ce9si13058482pfv.347.2022.11.29.07.38.51; Tue, 29 Nov 2022 07:39:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235720AbiK2PSb (ORCPT + 85 others); Tue, 29 Nov 2022 10:18:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235746AbiK2PSE (ORCPT ); Tue, 29 Nov 2022 10:18:04 -0500 Received: from outbound-smtp35.blacknight.com (outbound-smtp35.blacknight.com [46.22.139.218]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90D0011C27 for ; Tue, 29 Nov 2022 07:17:56 -0800 (PST) Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp35.blacknight.com (Postfix) with ESMTPS id 520BC1C60 for ; Tue, 29 Nov 2022 15:17:55 +0000 (GMT) Received: (qmail 5288 invoked from network); 29 Nov 2022 15:17:55 -0000 Received: from unknown (HELO morpheus.112glenside.lan) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPA; 29 Nov 2022 15:17:55 -0000 From: Mel Gorman To: Linux-MM Cc: Andrew Morton , Michal Hocko , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , LKML , Mel Gorman Subject: [PATCH 4/6] mm/page_alloc: Explicitly define what alloc flags deplete min reserves Date: Tue, 29 Nov 2022 15:16:59 +0000 Message-Id: <20221129151701.23261-5-mgorman@techsingularity.net> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20221129151701.23261-1-mgorman@techsingularity.net> References: <20221129151701.23261-1-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As there are more ALLOC_ flags that affect reserves, define what flags affect reserves and clarify the effect of each flag. Signed-off-by: Mel Gorman --- mm/internal.h | 3 +++ mm/page_alloc.c | 36 +++++++++++++++++++++++------------- 2 files changed, 26 insertions(+), 13 deletions(-) diff --git a/mm/internal.h b/mm/internal.h index 9a9d9b5ee87f..370500718732 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -757,6 +757,9 @@ unsigned int reclaim_clean_pages_from_list(struct zone *zone, #define ALLOC_HIGHATOMIC 0x200 /* Allows access to MIGRATE_HIGHATOMIC */ #define ALLOC_KSWAPD 0x800 /* allow waking of kswapd, __GFP_KSWAPD_RECLAIM set */ +/* Flags that allow allocations below the min watermark. */ +#define ALLOC_RESERVES (ALLOC_HARDER|ALLOC_MIN_RESERVE|ALLOC_HIGHATOMIC|ALLOC_OOM) + enum ttu_flags; struct tlbflush_unmap_batch; diff --git a/mm/page_alloc.c b/mm/page_alloc.c index e2b65767dda0..85a87d0ac57a 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3944,15 +3944,14 @@ ALLOW_ERROR_INJECTION(should_fail_alloc_page, TRUE); static inline long __zone_watermark_unusable_free(struct zone *z, unsigned int order, unsigned int alloc_flags) { - const bool alloc_harder = (alloc_flags & (ALLOC_HARDER|ALLOC_OOM)); long unusable_free = (1 << order) - 1; /* - * If the caller does not have rights to ALLOC_HARDER then subtract - * the high-atomic reserves. This will over-estimate the size of the - * atomic reserve but it avoids a search. + * If the caller does not have rights to reserves below the min + * watermark then subtract the high-atomic reserves. This will + * over-estimate the size of the atomic reserve but it avoids a search. */ - if (likely(!alloc_harder)) + if (likely(!(alloc_flags & ALLOC_RESERVES))) unusable_free += z->nr_reserved_highatomic; #ifdef CONFIG_CMA @@ -3976,25 +3975,36 @@ bool __zone_watermark_ok(struct zone *z, unsigned int order, unsigned long mark, { long min = mark; int o; - const bool alloc_harder = (alloc_flags & (ALLOC_HARDER|ALLOC_OOM)); /* free_pages may go negative - that's OK */ free_pages -= __zone_watermark_unusable_free(z, order, alloc_flags); - if (alloc_flags & ALLOC_MIN_RESERVE) - min -= min / 2; + if (alloc_flags & ALLOC_RESERVES) { + /* + * __GFP_HIGH allows access to 50% of the min reserve as well + * as OOM. + */ + if (alloc_flags & ALLOC_MIN_RESERVE) + min -= min / 2; - if (unlikely(alloc_harder)) { /* - * OOM victims can try even harder than normal ALLOC_HARDER + * Non-blocking allocations can access some of the reserve + * with more access if also __GFP_HIGH. The reasoning is that + * a non-blocking caller may incur a more severe penalty + * if it cannot get memory quickly, particularly if it's + * also __GFP_HIGH. + */ + if (alloc_flags & (ALLOC_HARDER|ALLOC_HIGHATOMIC)) + min -= min / 4; + + /* + * OOM victims can try even harder than the normal reserve * users on the grounds that it's definitely going to be in * the exit path shortly and free memory. Any allocation it * makes during the free path will be small and short-lived. */ if (alloc_flags & ALLOC_OOM) min -= min / 2; - else - min -= min / 4; } /* @@ -5293,7 +5303,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