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

[Li Wang <liwang@redhat.com>]

On Tue, Mar 24, 2026 at 07:49:17PM -0700, Yosry Ahmed wrote:
> 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?

Ah, that's 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.

nr_pages is 512, but you're right on the analysis.

> > +       }
> >         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).

Randomly dirty the page_size/2 always led to OOM, so I swith to page_size/4,
it looks like both algorithms compress pages successfully, but zstd doesn't
update 'zswpwb' stat so that test result fails.

Considering that zswap writeback is asynchronous, I additianlly introduced
a polling method for checking 500 times, but 'zswpwb' still returned zero.

==== Test results ====

lzo: 
  # uncompressed: 51511296, compressed: 13353876, ratio: 0.26
  # get_cg_wb_count(wb_group) is 206, get_cg_wb_count(control_group) is 0
  ok 7 test_no_invasive_cgroup_shrink

zstd:
  # uncompressed: 48037888, compressed: 12019013, ratio: 0.25
  # get_cg_wb_count(wb_group) is 0, get_cg_wb_count(control_group) is 0
  not ok 7 test_no_invasive_cgroup_shrink

==== debug code for the above output ====

  long zswapped = cg_read_key_long(control_group, "memory.stat", "zswapped");
  long zswap_compressed = cg_read_key_long(control_group, "memory.stat", "zswap");
  ksft_print_msg("uncompressed: %ld, compressed: %ld, ratio: %.2f\n",
		zswapped, zswap_compressed,
		(double)zswap_compressed / zswapped);
  ksft_print_msg("get_cg_wb_count(wb_group) is %zu, get_cg_wb_count(control_group) is %zu\n",
		get_cg_wb_count(wb_group),
		get_cg_wb_count(control_group));

In summary, the problem is that 'zswpwb' does not update when zswap is executed
under the zstd algorithm. I'd debugging this issue separately from the kernel side.

-- 
Regards,
Li Wang