On Mon, Sep 28, 2026 at 2:37 PM Hui Zhu <[email protected]> wrote: > > From: Hui Zhu <[email protected]> > > 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 <[email protected]> > --- [...] > + > + /* > + * 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
