Re: [PATCH v1 0/8] Batched zswap_store() with compression batching

[Kanchana P. Sridhar]

On Fri, Oct 16, 2026 at 9:14 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Thu, Oct 8, 2026 at 11:28 AM Kanchana P. Sridhar
> <kanchanapsridhar2026@xxxxxxxxx> wrote:
> >
> > v1: Batched zswap_store() with compression batching
> > ===================================================
> >
> > This series is a spin-off of "v14: zswap compression batching with optimized
> > iaa_crypto driver" [1], and focuses on the generic crypto_acomp and zswap
> > compression batching enablers. Resuming work on this series following a gap
> > since v14 (January 2026). Please note that my email address and affiliation have
> > changed from kanchana.p.sridhar@xxxxxxxxx to kanchanapsridhar2026@xxxxxxxxx. I
> > have retained the original Intel sign-offs on prior patches for historical
> > attribution while signing off v1 of this series with my current address.
> >
> > To summarize the main contribution of this patch series: Batching is introduced
> > in zswap_store() of large folios: we carve out a large folio into batches of
> > ZSWAP_MAX_BATCH_SIZE (8 pages) for software compressors, and store each
> > batch. Moving the fundamental operations that need to be happen to store a page
> > to now work at the granularity of a batch offers opportunities to optimize them
> > from these perspectives:
> >
> > 1) Utilize existing kernel API that minimize obtaining locks for bulk
> >    operations, e.g. kmem_cache_alloc_bulk()/kmem_cache_free_bulk().
> >
> > 2) We keep the working set for each of the core store functionalities (alloc
> >    entries, compress pages, store pages in zsmalloc) to be focused on a
> >    batch, thereby minimizing cache evictions and benefiting from cache
> >    locality.
> >
> > 3) Along the lines of (1), the main zswap_compress() batching routine obtains
> >    the acomp_ctx mutex lock once per batch, and releases it after it has
> >    processed all pages in that batch.
> >
> > 4) Any zswap store functionality that works on a batch can potentially be
> >    parallelized as a next step, to further improve performance.
> >
> > Performance data: usemem with 60% over-commit:
> > ==============================================
> > Validation was done with mm-unstable as of 10-3-2026 (Baseline) and with this
> > patch series.
> >
> > Testing was done on a Chromebook with a QEMU "vng" VM running in Crostini.
> >
> > Chromebook Diagnostics reports:
> >   Intel(R) Core(TM) Ultra 5 115U (10 CPUs, 4.200GHz)
> >   RAM: 16GB
> >
> > vng setup:
> >          Memory: 7G
> >            Swap: 3G
> >     Pinned CPUs: 4 (E-Cores: 4,5,6,7)
> >
> > zswap compressor:
> >   ZSTD
> >
> > mTHP enabled:
> >   64kB
> >
> > vm-scalability/usemem setup:
> >
> >   cgroup memory.high: 3G
> >   4 usemem processes, each allocates 1200M anonymous memory, reads the
> >   Silesia dataset [2] from a pre-fork-allocated buffer into the 1200M,
> >   writes to each unsigned long in the 1200M, sleeps for 10 sec, then
> >   frees the memory and exits.
> >
> >     usemem --read-silesia -w -O -b 1 -s 10 -n 4 1200M
>
> What is --read-silesia? Is this a local change you made to usemem?

Yes, this is a local change I made because I wanted to get compressed
lengths besides 565, which is the only compressed length of data
swapped out from the original usemem.

To replicate my setup:

1) Setup Silesia dataset to be read by usemem:

wget https://wanos.co/assets/silesia.tar
tar -xvf silesia.tar
# concatenate the 12 binary files into one
cat * >> /tmp/silesia.bin

2) Modifications to usemem:

usemem_orig.c is
https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git/tree/usemem.c.

diff usemem.c usemem_orig.c:

75,76d74
< unsigned long silesia_bytes = 211938580UL;
< char *silesia_dataset;
103d100
< int opt_read_silesia = 0;
166d162
<       "    --read-silesia      write memory with data from
Silesia.tar to allocate the pages from Linux kernel after
malloc/mmap\n"
209d204
<       { "read-silesia", 0, NULL,   0 },
352,373d346
< static void fill_buffer_from_silesia(char *buf, size_t length, const
char *silesia_path)
< {
<     size_t bytes_read = 0;
<
<     int fd = open(silesia_path, O_RDONLY);
<     if (fd < 0) {
<         perror("Failed to open Silesia dataset");
<         return;
<     }
<
<     while (bytes_read < length) {
<         ssize_t res = read(fd, buf + bytes_read, length - bytes_read);
<         if (res <= 0) {
<             /* Loop back to beginning of silesia.bin if allocation
exceeds ~210MB */
<             lseek(fd, 0, SEEK_SET);
<             continue;
<         }
<         bytes_read += res;
<     }
<     close(fd);
< }
<
613,623d585
< static inline void copy_silesia_to_buffer(char *from, char *to, size_t length)
< {
<       size_t nr_bytes_copied = 0, remaining_bytes;
<
<       while (nr_bytes_copied < length) {
<               remaining_bytes = min(silesia_bytes, length - nr_bytes_copied);
<               memcpy(to + nr_bytes_copied, from, remaining_bytes);
<               nr_bytes_copied += remaining_bytes;
<       }
< }
<
638,642d599
<
<               if (opt_read_silesia) {
<                       copy_silesia_to_buffer(silesia_dataset, (char
*)p, (size_t)bytes);
<               }
<
1053,1054d1009
<                       } else if (strcmp(opts[opt_index].name,
"read-silesia") == 0) {
<                               opt_read_silesia = 1;
1263,1268d1217
<       }
<
<
<       if (opt_read_silesia) {
<               silesia_dataset = (char *)allocate(silesia_bytes);
<               fill_buffer_from_silesia(silesia_dataset,
(size_t)silesia_bytes, "/tmp/silesia.bin");