From: Jinjiang Tu <tujinjiang@huawei.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: <david@kernel.org>, <ziy@nvidia.com>, <matthew.brost@intel.com>,
<joshua.hahnjy@gmail.com>, <rakie.kim@sk.com>, <byungchul@sk.com>,
<gourry@gourry.net>, <ying.huang@linux.alibaba.com>,
<apopple@nvidia.com>, <mgorman@suse.de>, <linux-mm@kvack.org>,
<wangkefeng.wang@huawei.com>
Subject: Re: [PATCH] mm/mempolicy: fix mpol_rebind_nodemask() for MPOL_F_NUMA_BALANCING
Date: Mon, 15 Dec 2025 09:40:03 +0800 [thread overview]
Message-ID: <4a40d056-306d-41b9-b79b-7519b4e8fbaf@huawei.com> (raw)
In-Reply-To: <20251214160459.1c9d9cfdec4088097ff6d713@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 3969 bytes --]
在 2025/12/15 8:04, Andrew Morton 写道:
> On Sat, 13 Dec 2025 16:29:11 +0800 Jinjiang Tu<tujinjiang@huawei.com> wrote:
>
>> When mempolicy is rebound due to the process moves to a different cpuset
>> context, or the set of nodes allowed by current cpuset context changes,
>> mpol_rebind_nodemask() remaps the nodemask according to the old and new
>> cpuset_mems_allowed by default. So, use mempolicy.w.cpuset_mems_allowed
>> to store the old nodemask allowed by cpuset.
>>
>> MPOL_F_STATIC_NODES suppresses the node remap and intersects the user's
>> passed nodemask and nodes allowed by new cpuset context.
>> For MPOL_F_RELATIVE_NODES, the user's passed nodemask means node IDs that
>> are relative to the set of node IDs allowed by the process's current
>> cpuset. So, use mempolicy.w.user_nodemask to store the user's passed
>> nodemask.
>>
>> commit bda420b98505 ("numa balancing: migrate on fault among multiple
>> bound nodes") adds new flag MPOL_F_NUMA_BALANCING to enable NUMA balancing
>> for MPOL_BIND, the behaviour of rebinding should be same with default
>> befaviour. However, mpol_store_user_nodemask() returns true for
>> MPOL_F_NUMA_BALANCING, leading to mempolicy.w.cpuset_mems_allowed stores
>> the user's passed nodemask instead of cpuset_current_mems_allowed, and
>> mpol_rebind_nodemask() remaps wrongly.
> Thanks.
>
> I find the changelog hard to follow, unfortunately. It's odd that the
> problem description comes in the final paragraph!
>
> I cheekily changed that and then fed the text into Gemini, which
> I think helped. What do you think of the below?
>
Thanks, it describes the problem more clearly. I will update the
commit log in the next version.
> I won't merge the patch at this time - I'll await reviewer input.
>
>
> ## Bug Fix: Corrected `MPOL_BIND` Rebinding with `MPOL_F_NUMA_BALANCING`
>
> ### Problem
>
> The commit `bda420b98505` ("numa balancing: migrate on fault among
> multiple bound nodes") introduced the new flag
> **`MPOL_F_NUMA_BALANCING`** to enable NUMA balancing for the
> **`MPOL_BIND`** memory policy.
>
> The intended behavior was for the rebinding logic to remain the same as
> the default `MPOL_BIND` behavior. However, the function
> `mpol_store_user_nodemask()` was incorrectly returning `true` for
> policies containing `MPOL_F_NUMA_BALANCING`.
>
> This led to a bug where:
>
> 1. `mempolicy.w.cpuset_mems_allowed` stored the **user's passed
> nodemask** instead of the actual nodemask allowed by the current
> cpuset context (`cpuset_current_mems_allowed`).
>
> 2. Consequently, **`mpol_rebind_nodemask()` performed incorrect
> remapping** when the mempolicy was rebound.
>
> ### Analysis of Correct Rebinding Logic
>
> When a memory policy is rebound (e.g., because the process moves to a
> different cpuset context, or the allowed nodes within the current
> cpuset change), `mpol_rebind_nodemask()`, by default, remaps the
> policy's nodemask based on the transition between the **old** and
> **new** `cpuset_mems_allowed` sets.
>
> To support this mechanism correctly, `mempolicy.w.cpuset_mems_allowed`
> **must store the old nodemask allowed by the cpuset** before the
> transition.
>
> ### Context for Other Flags
>
> * **`MPOL_F_STATIC_NODES`**: This flag suppresses the node remap and
> simply intersects the user's passed nodemask with the nodes allowed
> by the new cpuset context.
>
> * **`MPOL_F_RELATIVE_NODES`**: For this policy, the user's passed
> nodemask represents node IDs **relative** to the set of node IDs
> allowed by the process's current cpuset. Therefore,
> `mempolicy.w.user_nodemask` is correctly used to store the user's
> original relative nodemask.
>
> ### Proposed Fix
>
> Ensure that `mpol_store_user_nodemask()` handles
> `MPOL_F_NUMA_BALANCING` correctly so that
> `mempolicy.w.cpuset_mems_allowed` stores the correct cpuset-allowed
> nodemask, thereby restoring the proper remapping behavior in
> `mpol_rebind_nodemask()`.
>
[-- Attachment #2: Type: text/html, Size: 4575 bytes --]
next prev parent reply other threads:[~2025-12-15 1:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-13 8:29 Jinjiang Tu
2025-12-15 0:04 ` Andrew Morton
2025-12-15 1:40 ` Jinjiang Tu [this message]
2025-12-19 19:20 ` Gregory Price
2025-12-20 6:49 ` Jinjiang Tu
2025-12-19 19:23 ` Gregory Price
2025-12-21 7:06 ` Huang, Ying
2025-12-22 3:08 ` Jinjiang Tu
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=4a40d056-306d-41b9-b79b-7519b4e8fbaf@huawei.com \
--to=tujinjiang@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=mgorman@suse.de \
--cc=rakie.kim@sk.com \
--cc=wangkefeng.wang@huawei.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