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 21B0E49550A for ; Wed, 15 Jul 2026 19:08:38 +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=1784142523; cv=none; b=XtzpD+13YeafHB4wQR+cOv3ObfPeUb8p6FZLeg2w5TtQSAFx/AWOp9YG26jLxQcuRn4HHFe0xqySrQppGXenqVc1q8osr2qnlG7tWTF4hwv+CJpJh1JgFYRE+zP6lcTSqQMl5PRRRFfjX2d1QZ0ibR+A8ii+dyqdXXZlKbQkAJ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784142523; c=relaxed/simple; bh=9r8kJqQy+72m/rRtzysALP8vj9/tqSavjQ6gvvpPY8g=; h=Date:To:From:Subject:Message-Id; b=FvF86ENBi0tOxXnrL1RIONzXhEnVypzSxevWcXwNA3y5hxHgeFu13Q6JlrcT5kSKWtSVwipF1q8YeobdArL4MSbZ6UT1s0y2DQn0A60OmxOa593EH2hB1vJs07HZJ6MpCQpl3kSR2P9BbI5cs0ltnZ6MNRJmmIZaNUCcV9u5V9I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=GMAFsZKn; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="GMAFsZKn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D71241F000E9; Wed, 15 Jul 2026 19:08:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1784142514; bh=ykzFiN9j318iuOTtqhA9KL0RBfvRIxmwKy7geQbSDKY=; h=Date:To:From:Subject; b=GMAFsZKna2AMOn0YWPbd8bbXZ/EVtcze7PXhZT2hOiZHLJv4KjX6Q8/n/5swADqOe Yng6nsI168bemJ9tXwL6DR2a2ILtpRz8bM7KEbgteE5j9xsBLS4Qk00k2TSqp9aktv TqEK5LTXcWMgHs6CXXf1G6eGKHTGVCOnVLO0wLUY= Date: Wed, 15 Jul 2026 12:08:34 -0700 To: mm-commits@vger.kernel.org,ziy@nvidia.com,vbabka@kernel.org,tj@kernel.org,surenb@google.com,rppt@kernel.org,rostedt@goodmis.org,mkoutny@suse.com,mhocko@suse.com,longman@redhat.com,ljs@kernel.org,liam@infradead.org,hannes@cmpxchg.org,david@kernel.org,bigeasy@linutronix.de,jackmanb@google.com,akpm@linux-foundation.org From: Andrew Morton Subject: + cgroup-cpuset-update-some-comments-about-the-page-allocator.patch added to mm-new branch Message-Id: <20260715190834.D71241F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: cgroup/cpuset: update some comments about the page allocator has been added to the -mm mm-new branch. Its filename is cgroup-cpuset-update-some-comments-about-the-page-allocator.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/cgroup-cpuset-update-some-comments-about-the-page-allocator.patch This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. The mm-new branch of mm.git is not included in linux-next If a few days of testing in mm-new is successful, the patch will me moved into mm.git's mm-unstable branch, which is included in linux-next Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Brendan Jackman Subject: cgroup/cpuset: update some comments about the page allocator Date: Wed, 15 Jul 2026 11:03:19 +0000 These comments describing the page allocator are out of date: - __alloc_pages() is no longer a public API and has no business being described outside of mm/. - The `wait` variable is gone. It may be out of date for other reasons too but this patch is just fixing the issues that stood out. To fix it: - Instead of referring to a specific function, instead to "the page allocator" - Completely drop out-of-date details of that function's internal behaviour, since they were irrelevant anyway. Link: https://lore.kernel.org/20260715-spin-trylock-followup-v3-2-fc4d246f705d@google.com Signed-off-by: Brendan Jackman Suggested-by: Zi Yan Link: https://lore.kernel.org/all/DJP11T5V7BDW.2FZZZ8R6LOY4I@nvidia.com/ Reviewed-by: Zi Yan Reviewed-by: Vlastimil Babka (SUSE) Cc: David Hildenbrand Cc: Johannes Weiner Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Michal Koutný Cc: Mike Rapoport Cc: Sebastian Andrzej Siewior Cc: Steven Rostedt Cc: Suren Baghdasaryan Cc: Tejun Heo Cc: Waiman Long Signed-off-by: Andrew Morton --- kernel/cgroup/cpuset.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) --- a/kernel/cgroup/cpuset.c~cgroup-cpuset-update-some-comments-about-the-page-allocator +++ a/kernel/cgroup/cpuset.c @@ -4193,7 +4193,7 @@ static struct cpuset *nearest_hardwall_a * nearest enclosing hardwalled ancestor cpuset. * * Scanning up parent cpusets requires callback_lock. The - * __alloc_pages() routine only calls here with __GFP_HARDWALL bit + * page allocator only calls here with __GFP_HARDWALL bit * _not_ set if it's a GFP_KERNEL allocation, and all nodes in the * current tasks mems_allowed came up empty on the first pass over * the zonelist. So only GFP_KERNEL allocations, if all nodes in the @@ -4206,11 +4206,8 @@ static struct cpuset *nearest_hardwall_a * come before the __GFP_HARDWALL check, otherwise a dying task * would be blocked on the fast path. * - * The second pass through get_page_from_freelist() doesn't even call - * here for GFP_ATOMIC calls. For those calls, the __alloc_pages() - * variable 'wait' is not set, and the bit ALLOC_CPUSET is not set - * in alloc_flags. That logic and the checks below have the combined - * affect that: + * The second pass through get_page_from_freelist() doesn't even call here for + * GFP_ATOMIC calls. That, and the checks below have the combined affect that: * in_interrupt - any node ok (current task context irrelevant) * GFP_ATOMIC - any node ok * tsk_is_oom_victim - any node ok @@ -4327,8 +4324,8 @@ void cpuset_nodes_allowed(struct cgroup * should not be possible for the following code to return an * offline node. But if it did, that would be ok, as this routine * is not returning the node where the allocation must be, only - * the node where the search should start. The zonelist passed to - * __alloc_pages() will include all nodes. If the slab allocator + * the node where the search should start. The zonelist used by + * the allocator will include all nodes. If the slab allocator * is passed an offline node, it will fall back to the local node. * See kmem_cache_alloc_node(). */ _ Patches currently in -mm which might be from jackmanb@google.com are mm-page_alloc-drop-flag-conversion-optimisation.patch mm-secretmem-disable-under-highmem.patch mm-page_alloc-rename-alloc_trylock-alloc_nolock.patch mm-page_alloc-some-renames-to-clarify-alloc_flags-scopes.patch mm-name-some-args-in-a-function-declaration.patch mm-split-out-internal-page_alloch.patch mm-page_alloc-unify-__alloc_frozen_pages_noprof.patch mm-page_alloc-relax-gfp-warn-in-nolock-allocs.patch mm-move-some-stuff-to-mm-page_alloch.patch perf-x86-intel-use-higher-level-allocator-api.patch kvm-vmx-use-higher-level-allocator-api.patch x86-virt-use-higher-level-allocator-api.patch sgi-xp-use-higher-level-allocator-api.patch net-funeth-switch-to-higher-level-allocator-api.patch mm-remove-__alloc_pages_node.patch mm-move-__alloc_pages-to-mm-page_alloch.patch mm-replace-__gfp_no_codetag-with-alloc_no_codetag.patch mm-page_alloc-drop-alloc_flags-arg-from-alloc_flags_cma.patch mm-factor-out-can_spin_trylock.patch mm-page_alloc-rename-fpi_trylock-fpi_nolock.patch cgroup-cpuset-update-some-comments-about-the-page-allocator.patch mm-page_alloc-fixup-alloc_pages_nolock_noprof-comment.patch mm-page_alloc-remove-a-couple-of-vm_bug_onst.patch