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

[Yosry Ahmed]

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?