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

[Barry Song]

On Thu, Oct 8, 2026 at 3:10 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>
[...]

> +
> +       /*
> +        * Both candidate directories can be tmpfs (initramfs-based CI, for
> +        * instance). That is an environment limitation, not a test failure.
> +        */
> +       dir = workload_dir();
> +       if (!dir) {
> +               test__skip();
> +               return;
> +       }
> +
> +       snprintf(data_file, sizeof(data_file),
> +                "%s/memcg_proactive_reclaim_XXXXXX", dir);
> +       data_fd = mkstemp(data_file);

If we can't write to the directory, will `mkstemp()` fail?
Should we check `access(dir, W_OK)` first?

> +       if (!ASSERT_GE(data_fd, 0, "mkstemp"))
> +               return;
> +

Best Regards
Barry