Re: [PATCH 2/2] mm/mempolicy: stop copying the nodemask in the interleave paths

From: David Hildenbrand (Arm)

Date: Thu Sep 17 2026 - 06:09:52 EST


On 9/16/26 18:27, Gregory Price wrote:
> 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).

Ah, my memory comes back. So confusing.

>
> 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?

A resend is probably easiest when modifying the commit message.

For adding more code comments an inline patch we can squash is also good enough.

(I prefer a resend because that shows the full clean picture, but without actual
code changes I don't care that much)

--
Cheers,

David