mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gregory Price <gourry@gourry.net>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kernel-team@meta.com,  akpm@linux-foundation.org, ziy@nvidia.com,
	matthew.brost@intel.com, joshua.hahnjy@gmail.com,
	 rakie.kim@sk.com, byungchul@sk.com,
	ying.huang@linux.alibaba.com,  apopple@nvidia.com,
	urezki@gmail.com, chenwandun@huawei.com
Subject: Re: [PATCH 2/2] mm/mempolicy: stop copying the nodemask in the interleave paths
Date: Wed, 16 Sep 2026 12:27:13 -0400	[thread overview]
Message-ID: <aqq_yv-cQvzuxr5D@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <d7f162eb-4214-456c-9d1b-a8623da61b45@kernel.org>

On Wed, Sep 16, 2026 at 05:57:22PM +0200, David Hildenbrand (Arm) wrote:
> On 8/29/26 03:59, Gregory Price wrote:
> > The interleave node selectors copy pol->nodes onto the stack so the mask
> > cannot change while they walk it.  nodemask_t is 128 bytes at
> > MAX_NUMNODES=1024, and two of the three run per folio fault.
> > 
> > The copy only buys consistency between the node count and the walk.
> > Drop the consistency and just bounds check the walk instead.
> 
> I think you should document here that accessing the node bitnmap is safe (is RCU
> responsible for that? I think yes), but it can get updated concurrently.
> 

Actually, not quite.

RCU stabilizes the weights and makes accessing them safe. RCU doesn't
help us with the node bitmasks themselves (we were using a cpuset cookie
to stabilize them to take a copy - but we're killin that here).

What makes it safe is that we detect the torn read condition (check for
an empty nodemask) and otherwise don't care about weight skews in the
weighted variant.

I think it's reasonable to add a couple comments to spell out.

Are you ok if I just spin an additional commit to tack on rather than
spin a new version just for comments?

> > +	 * The target was calculated in a separate loop, and a concurrent
> > +	 * rebind can change the total number of nodes.  Clamp this loop to
> > +	 * a single pass (nnodes) to keep the walk bounded by node count.
> 
> Might want to explicitly comment here that we are looking at a moving target and
> might race with node bitmap modifications.
> 

ack.

> > -	nnodes = read_once_policy_nodemask(pol, &nodemask);
> > +	nnodes = nodes_weight(pol->nodes);
> >  	if (!nnodes)
> >  		return numa_node_id();
> >  	target = ilx % nnodes;
> > -	nid = first_node(nodemask);
> > -	for (i = 0; i < target; i++)
> > -		nid = next_node(nid, nodemask);
> > +	nid = first_node(pol->nodes);
> 
> Similarly, I wonder whether we should spell out the raciness.
>

ack.

~Gregory

  reply	other threads:[~2026-09-16 16:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-29  1:59 [PATCH 0/2] mm/mempolicy: stop copying state " Gregory Price
2026-08-29  1:59 ` [PATCH 1/2] mm/mempolicy: use SRCU for the weighted interleave state Gregory Price
2026-09-16 15:48   ` David Hildenbrand (Arm)
2026-08-29  1:59 ` [PATCH 2/2] mm/mempolicy: stop copying the nodemask in the interleave paths Gregory Price
2026-09-02  9:00   ` Rakie Kim
2026-09-02 14:52     ` Gregory Price
2026-09-04  8:01       ` Rakie Kim
2026-09-04 15:50         ` Gregory Price
2026-09-07  8:57           ` Rakie Kim
2026-09-16 15:57   ` David Hildenbrand (Arm)
2026-09-16 16:27     ` Gregory Price [this message]
2026-09-17  9:49       ` David Hildenbrand (Arm)
2026-09-17 11:33         ` Gregory Price
2026-08-29 23:18 ` [PATCH 0/2] mm/mempolicy: stop copying state " Andrew Morton
2026-08-30 16:39   ` Gregory Price

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=aqq_yv-cQvzuxr5D@gourry-fedora-PF4VCD3F \
    --to=gourry@gourry.net \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=chenwandun@huawei.com \
    --cc=david@kernel.org \
    --cc=joshua.hahnjy@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.brost@intel.com \
    --cc=rakie.kim@sk.com \
    --cc=urezki@gmail.com \
    --cc=ying.huang@linux.alibaba.com \
    --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

all inboxes | Powered by JetHome®