BPF gains kfunc to drive proactive memcg reclaim
A sleepable SYSCALL-only helper lets policy programs reclaim from chosen cgroups without writing memory.reclaim.
Hui Zhu has posted a seventh revision of a bpf-next series that gives BPF programs a way to trigger proactive reclaim on a chosen memory cgroup, closing a gap where eBPF could watch memcg pressure but could not act on it.
Until now, reclaiming from a specific cgroup meant writing to memory.reclaim from userspace. The new sleepable kfunc, bpf_proactive_reclaim(), runs one reclaim pass on a target memcg so that when and how hard to reclaim becomes BPF policy rather than fixed kernel thresholds. Each call is clamped to a small batch of pages so a single invocation stays a bounded unit of work on shared queues and under the LRU lock; larger goals are left to the program by repeated calls.
The helper is limited to BPF_PROG_TYPE_SYSCALL programs so reclaim always runs in clean process context. Generic sleepable BPF can hold filesystem locks or sit in NOFS/NOIO paths where shrinkers could deadlock. SYSCALL programs can still queue the work asynchronously through bpf_wq or task_work, which keep that program type and process context. Nested reclaim is refused because the reclaim path overwrites task reclaim state.
The motivating use case is protecting high-priority workloads: a program watches PSI or refault stats on a pressured cgroup and, when they worsen, asynchronously reclaims lower-priority cgroups so the hot workload gets free pages. Zhu also points at vendor kernels that already ship private async-reclaim hooks for similar reasons, arguing a mainline BPF path would cut fragmentation once broader memory-controller BPF hooks land.
Selftests cover async reclaim under refault pressure and the case where the reclaim target is removed mid-flight, requiring the program to skip offlined or dying cgroups. Andrew Morton asked whether the reclaim path itself should grow nesting support; Kumar Kartikeya Dwivedi called the current guard mostly defensive given the call-site limits and preferred revisiting only if reentrancy becomes necessary. Dwivedi also asked why a swappiness argument discussed earlier was dropped from this revision.