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

[Yafang Shao]

On Fri, Oct 16, 2026 at 4:01 PM Chen, Yu C <yu.c.chen@xxxxxxxxx> wrote:
>
> 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.

I'm not sure whether this is a real use case or merely a theoretical
one. I'd suggest we not focus too much on purely theoretical scenarios
unless someone can demonstrate a practical need.

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

Right. I will introduce a cgroup::numab_mode field, but without a
cgroupfs interface file; it will be written through a BPF program.

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

We have no plan to support threaded cgroups for now. If a real need
arises, the BPF program can be extended to handle it, which would just
require more kfuncs.

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

I believe this should be implemented in userspace, not automatically
in the kernel. Use cases are always complex, and flexibility is
important here.

-- 
Regards
Yafang