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

[Yosry Ahmed <yosry@kernel.org>]

On Tue, Mar 24, 2026 at 7:26 PM Li Wang <liwang@redhat.com> wrote:
>
> On Tue, Mar 24, 2026 at 01:28:12PM -0700, Yosry Ahmed wrote:
> > > > 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?
> > >
> > > Not very sure, I guess each 64K page contains 1 byte of 'a' and 65535 bytes
> > > of zero. A single page like that compresses down to roughly 20–30 bytes
> > > (a short literal plus a very long zero run, plus frame/header overhead).
> > > So the estimate is roughly 512 × 25 bytes ≈ 12.8 KB, which is where the
> > > "11 to 15 kilobytes" ballpark comes from.
> > >
> > > > Especially with different compressors? If it's close to 64K, this
> > > > might be a problem.
> > >
> > > Yes, good point, when I swith to use 'zstd' compressor, it doesn't work.
> > >
> > > > Maybe we can fill half of each page with increasing values? It should
> > > > still be compressible but not too compressible.
> > >
> > > I tried, this method works on Lzo algorithm but not Zstd.
> > > Anyway, I am still investigating.
> >
> > Do you mean the compressibility is still very high on zstd? I vaguely
> > remember filling a page with repeating patterns (e.g. alphabet
> > letters) seemed to produce a decent compression ratio, but I don't
> > remember the specifics.
> >
> > I am pretty sure an LLM could figure out what values will work for
> > different compression algorithms :)
>
> Well, I have tried many ways for ditry each page of the total, but none
> works on zstd compreseor.
>
> e.g,.
>
> --- a/tools/testing/selftests/cgroup/test_zswap.c
> +++ b/tools/testing/selftests/cgroup/test_zswap.c
> @@ -9,6 +9,7 @@
>  #include <string.h>
>  #include <sys/wait.h>
>  #include <sys/mman.h>
> +#include <sys/random.h>
>
>  #include "kselftest.h"
>  #include "cgroup_util.h"
> @@ -473,8 +474,12 @@ static int test_no_invasive_cgroup_shrink(const char *root)
>         if (cg_enter_current(control_group))
>                 goto out;
>         control_allocation = malloc(control_allocation_size);
> -       for (int i = 0; i < control_allocation_size; i += page_size)
> -               control_allocation[i] = (char)((i / page_size) + 1);
> +       unsigned int nr_pages = control_allocation_size/page_size;
> +       for (int i = 0; i < nr_pages; i++) {
> +               unsigned long off = (unsigned long)i * page_size;
> +               memset(&control_allocation[off], 0, page_size);
> +               getrandom(&control_allocation[off], nr_pages/2, 0);

This should be page_size/2, right?

nr_pages is 1024 IIUC, so that's 512 bytes only. If the page size is
64K, we're leaving 63.5K (99% of the page) as zeroes.


> +       }
>         if (cg_read_key_long(control_group, "memory.stat", "zswapped") < 1)
>                 goto out;
>
> Even I tried to set random data for all of the pages, they still not
> works (zstd). But it can be worked on lzo compressor, I don't know if
> the zstd have any addtional configures or I missed anything there.
>
> My current thought is just to satisfy the lzo (default) compressor in
> this patch series, and leave the zstd for additional work.
>
> What do you think? any better idea?

Let's check if using page_size/2 fixes it first. If a page is 100%
filled with random data it should be incompressible, so I would be
surprised if 50% random data yields a very high compression ratio.

It would also help if you check what the compression ratio actually is
(i.e. compressed_size / uncompressed_size).