On Mon, Sep 14, 2026 at 1:36 PM Harry Yoo (Meta) <[email protected]> wrote: > > The zswap_writeback_enabled test fails when a write to memory.reclaim > returns -EAGAIN, which means less than the requested amount was > reclaimed. attempt_writeback() propagates the -EAGAIN to the caller, > and the test case is marked as failed even when zswap writeback did > happen. > > This heavily depends on the performance of the backing swap device. > Reclaim does not wait for writeback (on cgroup v2), does not count pages > that are under writeback as reclaimed, and memory.reclaim gives up after > MAX_RECLAIM_RETRIES passes without making progress. On a slow device > where reclaim does not make any progress before writeback completes, > a write to memory.reclaim fails. > > On a VM with zswap enabled, where IO delay was injected via dm-delay, > the success rate of the zswap writeback test drops dramatically once > the delay reaches 11 ms: 7% failures at 10 ms and 79% failures at 11 ms, > n = 100. > > When zswap writeback is enabled, ignore -EAGAIN from memory.reclaim and > determine pass/fail based on the zswpwb counter because that is what > zswap_writeback_enabled actually wants to test. > > With this change, the test reliably passes even on a slow swap device > (tested up to 1000 ms delay). This makes the test resilient against > the performance of the swap device. > > Assisted-by: LLM > Fixes: 158863e5d7cc ("selftests: cgroup: add tests to verify the zswap > writeback path") > Signed-off-by: Harry Yoo (Meta) <[email protected]>
Acked-by: Nhat Pham <[email protected]>
