Re: [PATCH v4 0/7] selftests/cgroup: improve zswap tests robustness and support large page sizes

[Yosry Ahmed <yosry@kernel.org>]

On Sun, Mar 22, 2026 at 8:23 PM Li Wang <liwang@redhat.com> 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 <liwang@redhat.com> 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/20260322061038.156146-1-liwang@redhat.com
>
> > [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.