On 9/16/26 17:12, Kumar Kartikeya Dwivedi wrote: > On Tue Sep 15, 2026 at 7:26 PM CEST, Shakeel Butt wrote: >> On Tue, Sep 15, 2026 at 08:29:35PM +0800, Hui Zhu wrote: >>> From: Hui Zhu <[email protected]> >>> >>> 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 requires writing to memory.reclaim, which BPF >>> cannot do. >>> >>> Add bpf_proactive_reclaim(), a sleepable kfunc performing one >>> proactive reclaim pass on a memcg, like a write to memory.reclaim >>> but without retrying until the target is reached, so that when and >>> how hard to reclaim is BPF policy rather than hard-coded thresholds. >>> The reclaim target of a single call is capped at MEMCG_CHARGE_BATCH, >>> as high_work_func() does for memory.high; reclaiming more is left to >>> the program, which can call the kfunc once per bpf_wq callback and >>> stop at any point. It is limited to BPF_PROG_TYPE_SYSCALL, because >>> other sleepable programs may run with filesystem locks held, on >>> which the reclaim path could deadlock via filesystem shrinkers. >>> >>> Convert MIN_SWAPPINESS, MAX_SWAPPINESS and SWAPPINESS_ANON_ONLY from >>> macros to an enum so that they are emitted into BTF and usable from >>> BPF programs via vmlinux.h. >>> >>> Signed-off-by: Hui Zhu <[email protected]> >> >> Acked-by: Shakeel Butt <[email protected]> > > Hi Andrew and David, > > This looks good to me (from BPF side) and Shakeel, Hui might respin once more > to > address some of the selftest concerns. > > After that, any objections to taking this through bpf-next?
Fine with me, I don't expect any conflicts in mm/internal.h. -- Cheers, David
