Re: [PATCH 3/5] sched_ext: Scan NUMA hinting faults for opted-in BPF schedulers

From: Vladimir Vdovin

Date: Mon Oct 05 2026 - 07:34:50 EST


Hi Andrea,

Thanks for putting this together so quickly, and for picking up the RFC.

On Sun, Oct 04, 2026 at 09:27:09AM +0200, Andrea Righi wrote:
> + if (!queued && (sch->ops.flags & SCX_OPS_NUMA_BALANCING) &&
> + static_branch_unlikely(&sched_numa_balancing))
> + task_tick_numa(rq, donor);

One question about proxy execution, which I may well be missing context
on. Hui Su's tick series moves the fair NUMA tick to the execution
context, with the reasoning that task_tick_numa() works on the mm and
NUMA work state of the task that is actually running:

https://lore.kernel.org/r/20260909092901.2989564-3-sh_def@xxxxxxx

Here the scan is driven from the donor. I understand that in your proxy
execution integration SCX runtime is accounted to the donor, so maybe
this is intentional to keep the pacing consistent, but then the scan
would cover the donor's address space rather than the one being
accessed. Is the donor the intended choice here, or should this follow
rq->curr once SCHED_PROXY_EXEC no longer depends on !SCHED_CLASS_EXT?

Thanks,
Vladimir