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

[Chen, Yu C]

On 10/16/2026 3:38 PM, Yafang Shao wrote:
> On Fri, Oct 16, 2026 at 1:51 PM Chen Yu <yu.c.chen@xxxxxxxxx> 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