From: Waiman Long <llong@redhat.com>
To: Gregory Price <gourry@gourry.net>, cgroups@vger.kernel.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, tj@kernel.org, hannes@cmpxchg.org,
mkoutny@suse.com, mhocko@kernel.org, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, muchun.song@linux.dev,
akpm@linux-foundation.org
Subject: Re: [PATCH 1/2] cpuset: rename cpuset_node_allowed to cpuset_current_node_allowed
Date: Fri, 18 Apr 2025 21:59:04 -0400 [thread overview]
Message-ID: <9bcb139c-451b-4ea5-b4ff-21916372d94e@redhat.com> (raw)
In-Reply-To: <20250418031352.1277966-1-gourry@gourry.net>
On 4/17/25 11:13 PM, Gregory Price wrote:
> Rename cpuset_node_allowed to reflect that the function checks the
> current task's cpuset.mems. This allows us to make a new
> cpuset_node_allowed function that checks a target cgroup's cpuset.mems.
>
> Signed-off-by: Gregory Price <gourry@gourry.net>
> ---
> include/linux/cpuset.h | 4 ++--
> kernel/cgroup/cpuset.c | 4 ++--
> mm/page_alloc.c | 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
> index 835e7b793f6a..893a4c340d48 100644
> --- a/include/linux/cpuset.h
> +++ b/include/linux/cpuset.h
> @@ -82,11 +82,11 @@ extern nodemask_t cpuset_mems_allowed(struct task_struct *p);
> void cpuset_init_current_mems_allowed(void);
> int cpuset_nodemask_valid_mems_allowed(nodemask_t *nodemask);
>
> -extern bool cpuset_node_allowed(int node, gfp_t gfp_mask);
> +extern bool cpuset_current_node_allowed(int node, gfp_t gfp_mask);
>
> static inline bool __cpuset_zone_allowed(struct zone *z, gfp_t gfp_mask)
> {
> - return cpuset_node_allowed(zone_to_nid(z), gfp_mask);
> + return cpuset_current_node_allowed(zone_to_nid(z), gfp_mask);
> }
>
> static inline bool cpuset_zone_allowed(struct zone *z, gfp_t gfp_mask)
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 0f910c828973..d6ed3f053e62 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -4090,7 +4090,7 @@ static struct cpuset *nearest_hardwall_ancestor(struct cpuset *cs)
> }
>
> /*
> - * cpuset_node_allowed - Can we allocate on a memory node?
> + * cpuset_current_node_allowed - Can current task allocate on a memory node?
> * @node: is this an allowed node?
> * @gfp_mask: memory allocation flags
> *
> @@ -4129,7 +4129,7 @@ static struct cpuset *nearest_hardwall_ancestor(struct cpuset *cs)
> * GFP_KERNEL - any node in enclosing hardwalled cpuset ok
> * GFP_USER - only nodes in current tasks mems allowed ok.
> */
> -bool cpuset_node_allowed(int node, gfp_t gfp_mask)
> +bool cpuset_current_node_allowed(int node, gfp_t gfp_mask)
> {
> struct cpuset *cs; /* current cpuset ancestors */
> bool allowed; /* is allocation in zone z allowed? */
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 5079b1b04d49..233ce25f8f3d 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3461,7 +3461,7 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
> retry:
> /*
> * Scan zonelist, looking for a zone with enough free.
> - * See also cpuset_node_allowed() comment in kernel/cgroup/cpuset.c.
> + * See also cpuset_current_node_allowed() comment in kernel/cgroup/cpuset.c.
> */
> no_fallback = alloc_flags & ALLOC_NOFRAGMENT;
> z = ac->preferred_zoneref;
> @@ -4148,7 +4148,7 @@ gfp_to_alloc_flags(gfp_t gfp_mask, unsigned int order)
> /*
> * Ignore cpuset mems for non-blocking __GFP_HIGH (probably
> * GFP_ATOMIC) rather than fail, see the comment for
> - * cpuset_node_allowed().
> + * cpuset_current_node_allowed().
> */
> if (alloc_flags & ALLOC_MIN_RESERVE)
> alloc_flags &= ~ALLOC_CPUSET;
Acked-by: Waiman Long <longman@redhat.com>
prev parent reply other threads:[~2025-04-19 1:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-18 3:13 [PATCH 1/2] cpuset: rename cpuset_node_allowed to cpuset_current_node_allowed Gregory Price
2025-04-18 3:13 ` [PATCH v2 2/2] vmscan,cgroup: apply mems_effective to reclaim Gregory Price
2025-04-19 2:06 ` Waiman Long
2025-04-19 3:47 ` Gregory Price
2025-04-19 3:53 ` Waiman Long
2025-04-19 3:06 ` Tejun Heo
2025-04-19 3:27 ` Gregory Price
2025-04-19 3:41 ` Gregory Price
2025-04-19 3:47 ` Waiman Long
2025-04-19 1:59 ` Waiman Long [this message]
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=9bcb139c-451b-4ea5-b4ff-21916372d94e@redhat.com \
--to=llong@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.