Re: [PATCH bpf-next v7 0/2] bpf: BPF-driven proactive memcg reclaim

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Fri Sep 4, 2026 at 12:20 PM CEST, Hui Zhu wrote:
> From: Hui Zhu <zhuhui@kylinos.cn>
>
> BPF programs can observe memory pressure on a cgroup (e.g. refault
> stats via bpf_mem_cgroup_page_state()), but cannot act on it:
> triggering reclaim on a chosen cgroup requires writing to
> memory.reclaim, which BPF cannot do. This series adds
> bpf_proactive_reclaim(), a sleepable kfunc performing one proactive
> reclaim pass on a target memcg, so when and how hard to reclaim is
> BPF policy rather than hard-coded thresholds.
>
> The kfunc is restricted to BPF_PROG_TYPE_SYSCALL so that reclaim
> always runs in a clean process context: generic sleepable programs
> may execute with filesystem locks held or in NOFS/NOIO contexts,
> where the reclaim path could deadlock in filesystem shrinkers. The
> bpf_wq and task_work callbacks of a SYSCALL program keep its program
> type and run in process context, so reclaim work can still be queued
> asynchronously through them, as the selftest does with bpf_wq.
>
> The use case we are looking at is protecting high-priority workloads:
> a BPF program monitors the state of a high-priority cgroup and, when
> it degrades (e.g. PSI rises or refaults increase, as in the
> selftest), asynchronously reclaims memory from low-priority cgroups
> via bpf_wq and bpf_proactive_reclaim(), giving the pressured cgroup
> more free pages.
>
> Another use case: several vendor-maintained kernels carry private
> implementations that trigger asynchronous reclaim when a memcg enters
> a certain state. These exist for historical and partly psychological
> reasons, but the underlying demand is real. We expect BPF-driven
> proactive reclaim, combined with the BPF hooks for the memory
> controller currently under discussion and development, to serve these
> needs in mainline, reducing kernel fragmentation and improving kernel
> maintainability.

From BPF perspective this looks ok to me. I saw you dropped the swappiness
argument, what happened there? I thought we agreed to just include it in the
kfunc now. Did something change?