On Tue, Mar 24, 2026 at 7:26 PM Li Wang <[email protected]> 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).
