On Sun, Mar 22, 2026 at 8:23 PM Li Wang <[email protected]> wrote: > > On Sun, Mar 22, 2026 at 09:18:51AM -0700, Andrew Morton wrote: > > On Sun, 22 Mar 2026 14:10:31 +0800 Li Wang <[email protected]> wrote: > > > > > This patchset aims to fix various spurious failures and improve the > > > overall > > > robustness of the cgroup zswap selftests. > > > > AI review has questions: > > > > https://sashiko.dev/#/patchset/[email protected] > > > [Sashiko comments in patch 4/7] > > ... > > Could we update this loop, along with the identical loops in > > alloc_anon_noexit() and alloc_anon_50M_check_swap() shown below, to use > > sysconf(_SC_PAGESIZE) instead? > > I found that Waiman submit another patch that do same thing like this > suggestion. I'd consider to merge that one into my patch 4/7. > > So, let me talk to Waiman first.
Probably fits better in your patch. > > The test data is generated by writing a single 'a' character per page, > > leaving > > the rest zero-filled: > > > for (int i = 0; i < control_allocation_size; i += pagesize) > > control_allocation[i] = 'a'; > > > This makes the data highly compressible. Because memory.max is set to half > > of > > control_allocation_size, 512 pages are pushed into zswap. > > > 512 pages of mostly zeros can compress down to roughly 11 to 15 kilobytes > > using compressors like zstd, which is well below the 65536 byte (64k) > > zswap.max limit on a 64k page system. > > > Since the limit might not be reached, writeback might never trigger, > > causing the test to falsely fail. Should the test use incompressible data > > or a lower fixed limit? > > If Sashiko suggests reducing compressibility, we'd need to fill a significant > fraction of each page with varied data, but that would work against the test: > > zswap would reject poorly compressing pages and send them straight to swap, > and memory.stat:zswapped might never reach the threshold the test checks > with cg_read_key_long(..., "zswapped") < 1. > > So, at most I'd keep the data highly compressible and just ensure non-zero, > unique-per-page markers. Sashiko claims that 512 pages will end up consuming 11K to 15K in zswap with this setup, do you know what the actual number is? Especially with different compressors? If it's close to 64K, this might be a problem. Maybe we can fill half of each page with increasing values? It should still be compressible but not too compressible.
