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

[Hui Zhu <hui.zhu@linux.dev>]

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

Nothing changed. I misunderstood the earlier discussion and dropped the
swappiness argument by mistake. The plan to include it in the kfunc
still stands, and I will add it back in the next version.

Best,
Hui