Re: [PATCH bpf-next v11 1/2] mm/bpf: Add bpf_proactive_reclaim kfunc

["David Hildenbrand (Arm)" <david@kernel.org>]

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 <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 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 <zhuhui@kylinos.cn>
>>
>> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> 
> 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