Re: [PATCH 0/4] sched/numa: Add per-process automatic NUMA balancing control

["Chen, Yu C" <yu.c.chen@intel.com>]

On 10/16/2026 3:38 PM, Yafang Shao wrote:
> On Fri, Oct 16, 2026 at 1:51 PM Chen Yu <yu.c.chen@intel.com> wrote:
>> A more complex scenario is when cgroup A and cgroup B become threaded domains:
>>
>>                           root
>>                          /    \
>>                         X      Y
>>                         |      |
>>                         A      B          A, B: threaded domains (thread roots)
>>                        / \    / \         separate memory.max / io.max
>>                      A1   A2 B1  B2       threaded cgroups
>>                      ^        ^
>>                      |        |
>>                      +--------+
>>                    want to share one cache group
>>
>> In the above case, we might need to change the deployed cgroup hierarchy.
> 
> I think we can enable LLC-aware scheduling for both A1 and A2 — does
> that sound right?
> 

Here A1 wants to share data with B1, but A2 does not want to share data
with B2 nor B1 nor A1. Enabling cache-aware for A1 and A2 might not help
in this case.

>>
>> Suppose threads in A1 and threads in A2 belong to the same process Pa,
>> this reminds me of the cgroup bpf NUMA balancing case: after enabling
>> NUMA balancing for A1 but not setting it for A2, what would be the final
>> NUMA balancing decision for process Pa, is it enabled or disabled?
>> The NUMA balancing scan/invalid seems to be per process, so if we change
>> the setting of its threads, the whole process will be impacted. Or maybe
>> we should not enable NUMA balancing for threaded cgroups? Anyway I haven't
>> digged into your cgroup bpf patch set yet, let me try to look at it.
> 
> cgroup NUMAB works the same way: the setting is per cgroup and opt-in.
> For Pa in your example, since its threads spread across A1 and A2, you
> would enable it on both — enabling it on only one of them is not
> meaningful.
> 

I see. I haven't yet digged into your code, is there a per cgroup flag
cgroup.numab.enabled? Would there be a logic in the kernel, when 
A1.numab.enabled
is written to true, the kernel detects all the other cgroups {X} that 
contains threads
share the same mm_struct as A1's threads/tasks, and then update {X}'s 
numab.enabled
to the same value as A1, to keep consistency? In summary, if threads are 
spread
cross different cgroups, when you set the enable flag for 1 cgroup, will the
kernel iterates all the other cgroups to update their flags as well? Or
leverage userspace to do that?

thanks,
Chenyu