Re: [RFC PATCH v3 bpf-next 0/5] BPF-based per-cgroup NUMA balancing mode selection

[Tejun Heo]

Hello, Yafang.

On Mon, Oct 19, 2026 at 02:41:52PM +0800, Yafang Shao wrote:
> An opt-out wins and binds the subtree: a DISABLED request anywhere in
> the chain opts the cgroup's tasks out entirely. Otherwise the requested
> bits OR together and the kernel reads them independently, the way
> kernel.numa_balancing reads them, so a combined NORMAL|TIERING engages
> both modes. A DISABLED request only speaks for the cgroup's tasks,
> never for its memory, which follows the remaining requests of its
> ancestors.

Can you explain the reasoning behind the basic design decisions?

- The folio paths resolve through folio_memcg() while the task paths use
  the task's cgroup. Why isn't the whole thing tied to memcg?

- Why do the task and folio paths combine the chain differently? DISABLED
  binds the subtree for tasks but is skipped for folios.

- Some of the folio paths already have the faulting task.
  should_numa_migrate_memory() takes @p, and the do_numa_page() and
  migrate_misplaced_folio() checks run in the faulting task's context.
  Why not use the task there?

Stepping back, the basic design decisions don't seem to have been
thought through, and the descriptions restate them at length without
explaining them. I'm not the best person to judge how useful the
feature is in practice, but getting this version into acceptable shape
is likely a lot more work than having someone who knows how to do it
just write it. I don't think it makes sense to drag this out and force
it into shape over many review rounds.

Thanks.

--
tejun