Re: [PATCH bpf-next v2] selftests/bpf: Add bpf_proactive_reclaim test

[Barry Song]

On Mon, Sep 28, 2026 at 2:37 PM Hui Zhu <hui.zhu@xxxxxxxxx> wrote:
>
> From: Hui Zhu <zhuhui@xxxxxxxxxx>
>
> bpf_proactive_reclaim() performs one bounded reclaim pass per call and,
> unlike a write to memory.reclaim, does not retry until the goal is
> reached.
>
> Charge 32 MiB of page cache to a cgroup, ask for all of it in one call,
> and check that the result is positive but well below the request: one
> pass is capped at MEMCG_CHARGE_BATCH pages, far short of 32 MiB on both
> 4K and 64K page kernels.
>
> The test deliberately covers only the kfunc itself. A full example of
> the intended asynchronous use, where a BPF program watches one cgroup's
> workingset refaults and reclaims another one from bpf_wq callbacks, is
> maintained out of tree at [1], released under GPLv2.
>
> Add CONFIG_MEMCG to the config fragment, without which mm/bpf_memcontrol.c
> is not built at all.
>
> [1] https://github.com/teawater/memcg-async-reclaim
>
> Signed-off-by: Hui Zhu <zhuhui@xxxxxxxxxx>
> ---
[...]
> +
> +       /*
> +        * Charge FILE_SIZE of page cache to the cgroup. Reading rather than
> +        * writing keeps the pages clean, so reclaim does not have to start
> +        * writeback before it can evict them.
> +        */
> +       if (!ASSERT_OK(ftruncate(data_fd, FILE_SIZE), "ftruncate"))
> +               goto out;
> +       for (off = 0; off < (off_t)FILE_SIZE; off += sizeof(buf))
> +               if (!ASSERT_GT(read(data_fd, buf, sizeof(buf)), 0, "read"))
> +                       goto out;
> +

In case we might map file holes to the zero PFN someday (not sure when),
this wouldn't necessarily give us page cache. So maybe write + fsync is
more future-proof? In that case, you could also drop the two lines of
comments.

Best Regards
Barry