Re: [PATCHSET v2 sched_ext/for-7.5] sched_ext: Add NUMA balancing support

[Andrea Righi <arighi@nvidia.com>]

On Tue, Oct 27, 2026 at 11:52:09AM +0100, Peter Zijlstra wrote:
> On Tue, Oct 27, 2026 at 05:13:29AM +0100, Andrea Righi wrote:
> 
> > Ideally the ultimate goal is to give BPF schedulers both controls that
> > NUMA balancing combines: moving a task to the node where its memory is
> > and moving the memory a task uses to the node where the task runs. This
> > series provides the first: with the preferred node available, a
> > scheduler can decide where to run the task. A second series, to follow
> > once this one lands, will provide the second: a kfunc that lets a
> > scheduler request the node a task's memory should migrate to.
> 
> Fair has no real control over the memory migration part either; why
> would you want to give BPF that?

Yeah, that's a fair point and the wording in the cover letter is a bit
too vague.

The use case behind the second part is accelerator/device locality,
discussed at LPC in the sched_ext MC [1]: with multi-GPU systems the
heaviest user of a task's host memory is often the device, which NUMA
balancing can't see, since hinting faults only track CPU accesses. So
memory follows the CPU even when it should stay close to the device, and
today the only option is to pin everything with numactl and/or disable
NUMA balancing.

But that needs to be discussed separately: as Gregory pointed out at
LPC, NUMA balancing needs some cleanups first, and the right interface
may not be BPF-specific at all (e.g., extending the home node concept of
set_mempolicy_home_node() to NUMA balancing, or a device-aware hint in
mm that both fair and ext could use, or something else).

The first step for now is to, at least, allow sched_ext to see the
preferred node computed by NUMA balancing, which is what this series
does.

[1] https://lpc.events/event/20/sessions/270/attachments/2223/5283/lpc-2026-sched_ext-mc-report.md

Thanks,
-Andrea