From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Waiman Long <longman@redhat.com>, Gregory Price <gourry@gourry.net>
Cc: Farhad Alemi <farhad.alemi@berkeley.edu>,
Andrew Morton <akpm@linux-foundation.org>,
Farhad Alemi <falemi@asu.edu>, Yury Norov <ynorov@nvidia.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>, Zi Yan <ziy@nvidia.com>,
Matthew Brost <matthew.brost@intel.com>,
Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed
Date: Mon, 22 Jun 2026 09:12:38 +0200 [thread overview]
Message-ID: <e629ca4a-69c8-4288-802a-9150ab9da4ee@kernel.org> (raw)
In-Reply-To: <9d8b650d-6faa-425a-8db7-1e206cb25158@redhat.com>
On 6/21/26 05:24, Waiman Long wrote:
> On 6/18/26 4:41 AM, David Hildenbrand (Arm) wrote:
>> On 6/16/26 17:23, Waiman Long wrote:
>>> Yes, taking newmems is a reasonable choice and there are pros and cons with each
>>> options. My focus is more on not changing how v1 cpuset behaves as it is well
>>> defined in the v1 cpusets.rst file:
>>>
>>> Requests by a task, using the sched_setaffinity(2) system call to
>>> include CPUs in its CPU affinity mask, and using the mbind(2) and
>>> set_mempolicy(2) system calls to include Memory Nodes in its memory
>>> policy, are both filtered through that task's cpuset, filtering out any
>>> CPUs or Memory Nodes not in that cpuset. The scheduler will not
>>> schedule a task on a CPU that is not allowed in its cpus_allowed
>>> vector, and the kernel page allocator will not allocate a page on a
>>> node that is not allowed in the requesting task's mems_allowed vector.
>>>
>>> v2, OTOH, is more vague as to what setting cpuset.mems will mean and we
>>> generally follow what v1 is doing, but we have more leeway of what we can do.
>>>
>>> Using newmems will make the above text not totally correct. At least the offline
>>> memory nodes will be filtered out which will not be utilized by the task when
>>> the offline node becomes online. That is why I am saying that we will have to
>>> correct the documentation if we want to make this change.
>> So IIUC:
>>
>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>> index 1335e437098e..cdfc615f35a5 100644
>> --- a/kernel/cgroup/cpuset.c
>> +++ b/kernel/cgroup/cpuset.c
>> @@ -2645,7 +2645,13 @@ void cpuset_update_tasks_nodemask(struct cpuset *cs)
>> migrate = is_memory_migrate(cs);
>> - mpol_rebind_mm(mm, &cs->mems_allowed);
>> + /*
>> + * For v1 we can have empty effective_mems, but we cannot
>> + * attach any tasks (see cpuset_can_attach_check()). For v2,
>> + * it's guaranteed to not be empty.
>> + */
>> + VM_WARN_ON_ONCE(nodes_empty(cs->effective_mems));
>> + mpol_rebind_mm(mm, &cs->effective_mems);
>> if (migrate)
>> cpuset_migrate_mm(mm, &cs->old_mems_allowed, &newmems);
>> else
>
> That is true, but I don't think we need a VM_WARN_ON_ONCE() here.
I'd prefer if we catch such stuff in the future more easily than running into
late divide-by-zero. Maybe we should check in mpol_rebind_mm() instead.
--
Cheers,
David
next prev parent reply other threads:[~2026-06-22 7:12 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 19:03 [PATCH] mm: don't allow empty relative nodemask in mpol_relative_nodemask() Yury Norov
2026-05-28 19:37 ` Waiman Long
2026-05-28 19:40 ` Yury Norov
2026-05-28 19:37 ` Matthew Wilcox
2026-05-28 19:41 ` Andrew Morton
2026-05-29 15:26 ` Joshua Hahn
2026-05-29 17:47 ` Yury Norov
2026-05-29 18:40 ` Joshua Hahn
2026-06-01 14:32 ` David Hildenbrand (Arm)
2026-06-02 8:44 ` Gregory Price
2026-06-02 9:19 ` David Hildenbrand (Arm)
2026-06-02 9:54 ` Gregory Price
2026-06-02 15:01 ` Farhad Alemi
2026-06-05 15:18 ` David Hildenbrand (Arm)
2026-06-09 23:57 ` [PATCH] cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Farhad Alemi
2026-06-10 0:53 ` Andrew Morton
2026-06-10 11:34 ` Gregory Price
2026-06-11 2:50 ` Waiman Long
2026-06-14 13:25 ` [PATCH v2] " Farhad Alemi
2026-06-15 8:08 ` David Hildenbrand (Arm)
2026-06-15 9:38 ` Gregory Price
2026-06-15 11:08 ` David Hildenbrand (Arm)
2026-06-15 11:19 ` Gregory Price
2026-06-15 11:39 ` David Hildenbrand (Arm)
2026-06-16 2:26 ` Waiman Long
2026-06-16 3:43 ` Waiman Long
2026-06-16 6:59 ` David Hildenbrand (Arm)
2026-06-16 13:44 ` Gregory Price
2026-06-16 15:27 ` Waiman Long
2026-06-16 15:23 ` Waiman Long
2026-06-18 8:41 ` David Hildenbrand (Arm)
2026-06-21 3:24 ` Waiman Long
2026-06-22 7:12 ` David Hildenbrand (Arm) [this message]
2026-06-16 3:44 ` Waiman Long
2026-05-29 8:47 ` [PATCH] mm: don't allow empty relative nodemask in mpol_relative_nodemask() kernel test robot
2026-05-29 8:58 ` kernel test robot
2026-05-29 12:45 ` kernel test robot
2026-05-29 12:47 ` kernel test robot
2026-06-01 14:06 ` David Hildenbrand (Arm)
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=e629ca4a-69c8-4288-802a-9150ab9da4ee@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=cgroups@vger.kernel.org \
--cc=falemi@asu.edu \
--cc=farhad.alemi@berkeley.edu \
--cc=gourry@gourry.net \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=longman@redhat.com \
--cc=matthew.brost@intel.com \
--cc=rakie.kim@sk.com \
--cc=stable@vger.kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ynorov@nvidia.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 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.