From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB6623E44E4 for ; Sun, 26 Jul 2026 22:23:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.69 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785104635; cv=none; b=LtYSuqz1hmPump3fN4VNKEP8aeGHNTukFcazepApkwmVOicf0fW3V+JtoyEH0V2AbBAZFhwaNDP4xndD8t4z4sOThAC4F66Bw1SXNuFL0XNXCfY/iPFiOCf5s+J/+rJdhqCULi12Xc4ZD7I9kzTYp49OZI+N/lmoHk8YBkSAZnA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785104635; c=relaxed/simple; bh=nm8W1OGku/ZIRz0hsuyApt62YSuxBnpwcWtt615ieHM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=GXfg8vyrB/0AhZkCbEFVr22w5NKWNYEpRW0wlLhA86CCcFQ9ROBsXHTvHQ7wpun/DeRBG9ZZqvS/K5kh9aTe6gCC51k5DBFcY5eETCqv9udBsqk0d5Q1mAnwBXhdwORJaP6Mu5lPmgLgKY/B+tTVTDhFjjCpiyv5QSmuZO2G0rg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Ya3OHFaL; arc=none smtp.client-ip=209.85.221.69 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Ya3OHFaL" Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-47f9ae25143so1723724f8f.2 for ; Sun, 26 Jul 2026 15:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785104630; x=1785709430; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=q7SCIRKoUCtKEBd3N+ZVZRVrBd5TKGm6OYIjsu4T5vE=; b=Ya3OHFaLWoGb5NUnj8fWPJTSvk8YEArfZB/fIZ878i3BH7/6c1hoYAJ7mwRWZ81g05 zsI9/GbF7ZZa5QIR/P7Uhmu75BIcSlb+eqYMbzLO7s1AxZkdHM5tVnGHYZHXT6vVQOeJ OCl8WR4s8naiHUD2nxRmXg9dxSuaB9HqU4DZEt1pTr7fvVof2hwgvfEfGurrFvvvUkrL SJD0X4fhcMDSVH6yLbCLfWq4Bibi/aYmp5suxA2luG4gBztHFkcgH/37u1Z84XN0T0tu pHyAmyF9lR6v5ZySLIjWQP5Gsd45mtP0MxHRVGBg6ugmfT4AByOT6Gw+JE9FTSKUUWzX 84nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785104630; x=1785709430; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=q7SCIRKoUCtKEBd3N+ZVZRVrBd5TKGm6OYIjsu4T5vE=; b=IFgXy11qlR6B2bwTt15k9E4NFiLxekpLlXvirbafOwrG6GoI1z+ka9p+n0xDE2uRKf Bv4So8oRqqB28VzKQ0xi5CwZKydqKpv53RBA6IGyEDuwqUB3JklWVEH2wJgAh98UkvpO yOYItp+Tj9qmjKakt/dy745jbYniazg5021a2L/RLy0+F5LEup5ZUMoj66JUtEHxZQUt 0hWZVis+E4CAcyRvP0fvYlQRD/ZTXy+7Y3LjxCKgKr1FwKLHTCX+zgQbioWvdVFxYmbg 8GXpOWeuDHFAKBiqjn5OTh0cgwRGYJkmO9QPy0VySIyjrHOHlvjeXo6Ln+sriKg1IVJe wZ5g== X-Forwarded-Encrypted: i=1; AHgh+RrTFbuo7ni8KjPjaS+uVgeUruUs7s1xFicjgfnwnQt7LHyL+PHDyMS1hemUnzZZJGpQrDY8rOv6plJqaYk=@vger.kernel.org X-Gm-Message-State: AOJu0YwpcYmdX2ZbKNnU2KUQWXuxcc8tlzaagfS/g3lOfLNLK58lc9Bn FNHTqWyFUhzUXNeYo5rlu16KUunlRq0UI9KdpOz030R+s1wOVslAHD+pjpjzGENfQKXve+5Yphi LXqdR7xukL820MA== X-Received: from wmbjq22.prod.google.com ([2002:a05:600c:55d6:b0:490:e19b:c5ab]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:4595:b0:495:3a21:4e5d with SMTP id 5b1f17b1804b1-496b56f461dmr76997775e9.0.1785104629845; Sun, 26 Jul 2026 15:23:49 -0700 (PDT) Date: Sun, 26 Jul 2026 22:22:52 +0000 In-Reply-To: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> X-Mailer: b4 0.16-dev Message-ID: <20260726-page_alloc-unmapped-v3-19-6f5729aa9832@google.com> Subject: [PATCH v3 19/26] mm/page_alloc: rename ALLOC_NON_BLOCK back to _HARDER From: Brendan Jackman To: Borislav Petkov , Dave Hansen , Peter Zijlstra , Andrew Morton , David Hildenbrand , Vlastimil Babka , Mike Rapoport , Wei Xu , Johannes Weiner , Zi Yan , Lorenzo Stoakes Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, rppt@kernel.org, Sumit Garg , Will Deacon , rientjes@google.com, "Kalyazin, Nikita" , patrick.roy@linux.dev, "Itazuri, Takahiro" , Andy Lutomirski , David Kaplan , Thomas Gleixner , Yosry Ahmed , Patrick Bellasi , Reiji Watanabe , Sean Christopherson , Brendan Jackman Content-Type: text/plain; charset="utf-8" Commit 1ebbb21811b7 ("mm/page_alloc: explicitly define how __GFP_HIGH non-blocking allocations accesses reserves") renamed ALLOC_HARDER to ALLOC_NON_BLOCK because the former is "a vague description". However, vagueness is accurate here, this is a vague flag. It is not set for __GFP_NOMEMALLOC. It doesn't really mean "allocate without blocking" but rather "allow dipping into atomic reserves, _because_ of the need not to block". A later commit will need an alloc flag that really means "don't block here", so go back to the flag's old name and update the commentary to try and give it a slightly clearer meaning. Signed-off-by: Brendan Jackman --- mm/page_alloc.c | 8 ++++---- mm/page_alloc.h | 9 +++++---- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 30ba61c20209c..fb522a09f2e60 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3431,7 +3431,7 @@ struct page *rmqueue_buddy(struct zone *preferred_zone, struct zone *zone, * reserves as failing now is worse than failing a * high-order atomic allocation in the future. */ - if (!page && (alloc_flags & (ALLOC_OOM|ALLOC_NON_BLOCK))) + if (!page && (alloc_flags & (ALLOC_OOM|ALLOC_HARDER))) page = __rmqueue_smallest(zone, order, ft_high); if (!page) { @@ -3811,7 +3811,7 @@ bool __zone_watermark_ok(struct zone *z, unsigned int order, unsigned long mark, * or (GFP_KERNEL & ~__GFP_DIRECT_RECLAIM) do not get * access to the min reserve. */ - if (alloc_flags & ALLOC_NON_BLOCK) + if (alloc_flags & ALLOC_HARDER) min -= min / 4; } @@ -4733,7 +4733,7 @@ alloc_flags_nonblocking(gfp_t gfp_mask, unsigned int order) if (gfp_mask & __GFP_NOMEMALLOC) return 0; - alloc_flags |= ALLOC_NON_BLOCK; + alloc_flags |= ALLOC_HARDER; if (order > 0 && (gfp_mask & __GFP_HIGH)) alloc_flags |= ALLOC_HIGHATOMIC; @@ -4750,7 +4750,7 @@ alloc_flags_slowpath(gfp_t gfp_mask, unsigned int order) * The caller may dip into page reserves a bit more if the caller * cannot run direct reclaim, or if the caller has realtime scheduling * policy or is asking for __GFP_HIGH memory. GFP_ATOMIC requests will - * set both ALLOC_NON_BLOCK and ALLOC_MIN_RESERVE(__GFP_HIGH). + * set both ALLOC_HARDER and ALLOC_MIN_RESERVE(__GFP_HIGH). */ if (gfp_mask & __GFP_HIGH) alloc_flags |= ALLOC_MIN_RESERVE; diff --git a/mm/page_alloc.h b/mm/page_alloc.h index fac8e5304bb03..2307b173a459f 100644 --- a/mm/page_alloc.h +++ b/mm/page_alloc.h @@ -32,9 +32,10 @@ #define ALLOC_OOM ALLOC_NO_WATERMARKS #endif -#define ALLOC_NON_BLOCK 0x10 /* Caller cannot block. Allow access - * to 25% of the min watermark or - * 62.5% if __GFP_HIGH is set. +#define ALLOC_HARDER 0x10 /* Because the caller cannot block, + * allow access to 25% of the min + * watermark or 62.5% if __GFP_HIGH is + * set. */ #define ALLOC_MIN_RESERVE 0x20 /* __GFP_HIGH set. Allow access to 50% * of the min watermark. @@ -76,7 +77,7 @@ #endif /* Flags that allow allocations below the min watermark. */ -#define ALLOC_RESERVES (ALLOC_NON_BLOCK|ALLOC_MIN_RESERVE|ALLOC_HIGHATOMIC|ALLOC_OOM) +#define ALLOC_RESERVES (ALLOC_HARDER|ALLOC_MIN_RESERVE|ALLOC_HIGHATOMIC|ALLOC_OOM) /* * Structure for holding the mostly immutable allocation parameters passed -- 2.54.0