From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5092282F3A for ; Tue, 18 Aug 2026 00:45:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787013916; cv=none; b=tvkncanVXWtEbGLa/7M99dF4W6nzYmQIWwtyja7aTxzyTtiudXqTBDhzN9rVciPquUNroEQ6oFOsuw59j3/WtXii7lDrtpQ9HHERugeWGGEBbNXRZsqtUehlqXqnmznbL2/lj0XiaHd+Omd51XZZUNRgMWDXyG/L8z36fnQy+Cc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787013916; c=relaxed/simple; bh=KloxYiECB7QPK+dtEiqR1oOnQu4NzRWWfyOqtngIN/E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uKCHf0+KlhbfwZ7w//j8SQt0cj7b6luYxoypZX0nIuNrtPDIkyB3C907nFBBCTb9Ip/c4qEfAqsleA2yX4KCW2ZV33g3CMjC1sP6M6usLl+5jCo0GkdRmzNzakzsfx/b+qn7sG0V8xVKL8odFd5g0lIibQxsyV0WF9IlxBzxlQY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UCXeXMTz; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UCXeXMTz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E6DC1F000E9; Tue, 18 Aug 2026 00:45:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787013914; bh=Y7IBZ9whj8N27pOck+w1kYgcf4pKNDKFKbZGgA8fyUE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=UCXeXMTz+dlXORAFIthhGIBJp/jEko/vO888JKdoWD7GCBmXYh8ZESI9OoCouAQdD jHGxoQIiARkrkBpEeejYUwOSEA2iZLrskeL4TUwKK+F0oLrH8FNXzeQQIe6sMuQLjk lqn/tptC1D3yAN1dyZOTOU9LmmOybo56tyGPswn1J4TUXTtrUIooZx81tb/oTyByqH InLlzOwJecAefFVN8a43oEKRtI+p9bTg3err5T15cn2j/282kIOFJXvcirldJL7v6G QD3mGNyb4n6PSclOX4DjCNaY1I0xOp4MyUTkHAxDmySIMg+iCq91BMzypbt6cq0Dq5 4/U8nL4P/xizQ== Date: Tue, 18 Aug 2026 00:45:11 +0000 From: Yosry Ahmed To: Brendan Jackman Cc: "Vlastimil Babka (SUSE)" , Borislav Petkov , Dave Hansen , Peter Zijlstra , Andrew Morton , David Hildenbrand , Mike Rapoport , Wei Xu , Johannes Weiner , Zi Yan , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, Sumit Garg , Will Deacon , rientjes@google.com, patrick.roy@linux.dev, "Itazuri, Takahiro" , Andy Lutomirski , David Kaplan , Thomas Gleixner , Patrick Bellasi , Reiji Watanabe , Sean Christopherson Subject: Re: [PATCH v3 19/26] mm/page_alloc: rename ALLOC_NON_BLOCK back to _HARDER Message-ID: References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-19-6f5729aa9832@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Aug 14, 2026 at 01:09:32PM +0100, Brendan Jackman wrote: > On Tue Aug 4, 2026 at 10:50 PM BST, Yosry Ahmed wrote: > > On Fri, Jul 31, 2026 at 04:52:59PM +0200, Vlastimil Babka (SUSE) wrote: > >> On 7/27/26 00:22, Brendan Jackman wrote: > >> > 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 > > Writing this to get it clear in my head, so I'll also dump it in the > mail in case it helps get us on the same page... > > What we actually want here is a flag that tells us when we can do a TLB > shootdown. That means (on x86) that IRQs must be on and we mustn't be > holding some random spinlock (most spinlocks would actually be fine but > I think it's simpler to assume we can't hold any). > > It must never be over-permissive i.e. tell us we can do a TLB flush > when we can't. It's fine to _sometimes_ be over-restrictive i.e. tell us > we can't do a TLB flush when we can, but if it always forbids flushing > while GFP_BOOT_MASK is in effect then we'll fail critical allocations > and crash. Why is it a problem if it forbids flushing while GFP_BOOT_MASK is in effect? We should change gfp_allowed_mask before any unmapped allocations are possible, right? > > >> I wonder if we need to do this, and instead we could repurpose > >> ALLOC_NON_BLOCK directly. AFAIU it's about removing the side-effect of > >> gfp_allowed_mask in the next patch. But what would happen if we did that > >> using the existing ALLOC_NON_BLOCK (or maybe just renamed to ALLOC_NOBLOCK?). > >> > >> - in __zone_watermark_ok(), ALLOC_NON_BLOCK could now be *not* set in > >> situations where previously it was set due to gfp_allowed_mask masking out > >> __GFP_DIRECT_RECLAIM. > > Hm, I can't follow this. The first paragraph sounds like you're > proposing that we set ALLOC_NON_BLOCk regardless of gfp_allowed_mask. I > think that would be fine. But then the second paragraph is saying > ALLOC_NON_BLOCK would now be unset in places where it's formerly set, > whereas I think the proposal means it gets set in places it was formerly > unset. > > >> But it only has an effect on top of __GFP_HIGH (thus > >> ALLOC_MIN_RESERVE... which seems contradicting the ALLOC_NON_BLOCK > >> description comment btw). Also __GFP_DIRECT_RECLAIM is only masked out by > >> GFP_BOOT_MASK when all memory is free, so it's kinda moot? > > ... but yes, I do think making the existing ALLOC_NON_BLOCK ignore > gfp_allowed_mask would probably work. > > Aside from gfp_allowed_mask the other thing about ALLOC_NON_BLOCK is > that it gets disabled if __GFP_NOMEMALLOC is set. That is fine for the > current usecase, but it's pretty confusing... > > >> - in rmqueue_buddy() we allow access to highatomic reserves since > >> 281dd25c1a018. That commit describes GFP_ATOMIC so we could have been > >> checking ALLOC_MIN_RESERVE. But we can also leave this alone because it > >> doesn't actually matter when GFP_BOOT_MASK is set, as above. > > > > IIUC we are trying to find out if the callers either has interrupts > > disabled or is holding a lock, and using __GFP_DIRECT_RECLAIM as an > > indicator. As you mention, it seems like __GFP_DIRECT_RECLAIM is only > > masked during boot, presumably before we can allocate any unmapped > > memory (should always be user memory?). > > Exactly. > > > So maybe we should just use gfpflags_allow_blocking()? > > Oh yeah, it definitely should. This doesn't change any of the plumbing > challenges though since we've lost the GFP flags by the time we get to > __rmqueue_direct_map(). Yeah I think I prefer just using gfpflags_allow_blocking() if we cannot use preemtible(). > > > I also wonder if restricing to callers __GFP_DIRECT_RECLAIM is too > > restrictive, > > It is overly restrictive, but I dont' know of anything better, and if it > existed I think it would be in gfpflags_allow_blocking(). > > > we can probably key off __GFP_ATOMIC as I assume any > > callers with IRQs disabled or wiht a lock have to set it. > > There's no such thing as __GFP_ATOMIC. (I think there used to be?) Duh. > > > Maybe we can also use preemptible(), but that creates a dependency on > > CONFIG_PREEMPT_COUNT as far as I can tell. > > Yeah. Which... maybe is fine nowadays? Since commit 7dadeaa6e851 > ("sched: Further restrict the preemption modes") you can only set > PREEMPT_NONE on alpha/hexagon/m68k. And this restriction only actually > matters on x86 anyway... Yeah I will look into that. I like preemptible() because it encodes exactly what we actually need.