From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: "Brendan Jackman" <jackmanb@google.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Michal Hocko" <mhocko@suse.com>,
"Johannes Weiner" <hannes@cmpxchg.org>, "Zi Yan" <ziy@nvidia.com>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"Clark Williams" <clrkwllms@kernel.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Waiman Long" <longman@redhat.com>,
"Ridong Chen" <ridong.chen@linux.dev>,
"Tejun Heo" <tj@kernel.org>, "Michal Koutný" <mkoutny@suse.com>,
"David Hildenbrand" <david@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Mike Rapoport" <rppt@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH v3 2/4] cgroup/cpuset: update some comments about the page allocator
Date: Wed, 15 Jul 2026 15:16:28 +0200 [thread overview]
Message-ID: <ad397b95-bb3b-4f8f-b1e0-cbe204530721@kernel.org> (raw)
In-Reply-To: <20260715-spin-trylock-followup-v3-2-fc4d246f705d@google.com>
On 7/15/26 13:03, Brendan Jackman wrote:
> 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.
>
> Suggested-by: Zi Yan <ziy@nvidia.com>
> Link: https://lore.kernel.org/all/DJP11T5V7BDW.2FZZZ8R6LOY4I@nvidia.com/
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> kernel/cgroup/cpuset.c | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 24ea2d09cdbdb..dfd0f827e3b92 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -4193,7 +4193,7 @@ static struct cpuset *nearest_hardwall_ancestor(struct cpuset *cs)
> * 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_ancestor(struct cpuset *cs)
> * 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 *cgroup, nodemask_t *mask)
> * 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().
> */
>
next prev parent reply other threads:[~2026-07-15 13:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 11:03 [PATCH v3 0/4] mm/page_alloc: couple of followups for recent cleanups Brendan Jackman
2026-07-15 11:03 ` [PATCH v3 1/4] mm/page_alloc: rename FPI_TRYLOCK -> FPI_NOLOCK Brendan Jackman
2026-07-15 13:14 ` Vlastimil Babka (SUSE)
2026-07-15 11:03 ` [PATCH v3 2/4] cgroup/cpuset: update some comments about the page allocator Brendan Jackman
2026-07-15 13:16 ` Vlastimil Babka (SUSE) [this message]
2026-07-15 11:03 ` [PATCH v3 3/4] mm/page_alloc: fixup alloc_pages_nolock_noprof() comment Brendan Jackman
2026-07-15 13:17 ` Vlastimil Babka (SUSE)
2026-07-15 11:03 ` [PATCH v3 4/4] mm/page_alloc: remove a couple of VM_BUG_ON()st Brendan Jackman
2026-07-15 13:25 ` Vlastimil Babka (SUSE)
2026-07-15 13:48 ` Brendan Jackman
2026-07-15 13:56 ` Vlastimil Babka (SUSE)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ad397b95-bb3b-4f8f-b1e0-cbe204530721@kernel.org \
--to=vbabka@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=cgroups@vger.kernel.org \
--cc=clrkwllms@kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=ljs@kernel.org \
--cc=longman@redhat.com \
--cc=mhocko@suse.com \
--cc=mkoutny@suse.com \
--cc=ridong.chen@linux.dev \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox