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

[Yosry Ahmed <yosry@kernel.org>]

On Tue, Oct 27, 2026 at 08:04:55PM -0700, Kanchana P. Sridhar wrote:
> 
> v2: Batched zswap_store() framework 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@intel.com to kanchanapsridhar2026@gmail.com. I
> have retained the original Intel sign-offs on prior patches for historical
> attribution while signing off v2 of this series with my current address.
> 
> The main focus of v2 was to establish a reliable and accurate performance
> measurement methodology, that addressed the problems with variation in v1. This
> is accomplished and used to validate v2, by reducing usemem to 2 processes and
> enabling PMD THP. As the data shows, we get exactly the same "2048kB-zswpout"
> counts in the baseline and with this series.
> 
> 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/initialize zswap entries, compress pages, store pages in zsmalloc,
>    pool/objcg reference increments, objcg charging) 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 comp_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
>    optimized via bulk-processing/parallelized as a next step, to further improve
>    performance.
> 
> Performance data: usemem with 56% over-commit:
> ==============================================
> Validation was done with mm-unstable as of 10-25-2026 (Baseline) and with this
> patch series. To minimize variation in the data, I made these changes to my
> performance measurement methodology:
> 
> 1) Reduced the number of usemem processes to 2. Each process tried to allocate
>    2400M, in a 3G cgroup memory.high budget, effectively accomplishing a 56.25%
>    over-commit.
> 
> 2) Increased the runtime of the workload to ~9 minutes by enabling PMD THP,
>    i.e., 2048kB mTHP folios.
> 
> 3) The use of PMD THP forces zswap_store()/zswap_compress() latency to be in the
>    critical path, and thus enables very reliable measurements with bpftrace.
> 
> 4) I used lhist() instead of hist() in bpftrace to gather latencies at a finer
>    level of granularity and accuracy.
> 
> 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: 2 (E-Cores: 2,3)
> 
> zswap compressor:
>   ZSTD
> 
> mTHP enabled:
>   2048kB (PMD THP)
> 
> I used the help of an LLM to write the bpftrace data post-processing scripts
> that generate latency percentiles.
> 
> vm-scalability/usemem setup:
> 
>   cgroup memory.high: 3G
>   2 usemem processes, each allocates 2400M anonymous memory, reads the
>   Silesia dataset [2] from a pre-fork-allocated buffer into the 2400M,
>   writes to each unsigned long in the 2400M, sleeps for 10 sec, then
>   frees the memory and exits.
> 
>     usemem -w --read-silesia -O -b 1 -s 10 -n 2 2400M
> 
>  usemem metrics are reported from a single run after starting the QEMU VM.
>  Further, I have tabulated the bpftrace p50/p95/p99 latencies with these labels:
> 
>  "zswap_store_higher_order":
>     zswap_store() of PMD folios.
> 
>  "zswap_store_order_0":
>     zswap_store() of order-0 folios.
> 
>  "zswap_batch_compress_per_page":
>     zswap_compress() per-page latency of store batches generated from PMD
>     folios.
> 
>  "zswap_single_compress_per_page":
>     zswap_compress() per-page latency of order-0 folios.
> 
>  
>  ----------------------------------------------------------------------------
>  usemem                       Baseline      zswap        zswap   Change with
>  PMD THP                   mm-unstable      store     compress      compress
>                             10-25-2026   batching     batching      batching
>                                         (patch 6)    (patch 8)          %
>  ----------------------------------------------------------------------------
>  usemem process 1                6,353      7,240        7,428
>   Throughput (KB/s)
> 
>  usemem process 2                6,352      7,236        7,422   
>   Throughput (KB/s)
> 
>  Average Throughput (KB/s)       6,353      7,238        7,425        17%
>  ----------------------------------------------------------------------------
>  usemem process 1              484,580    308,903      257,230
>   Time to free memory (usecs)
> 
>  usemem process 2              518,928    438,585      446,958 
>   Time to free memory (usecs)
> 
>  Average Time to               501,754    373,744      352,094       -30%
>   Free Memory (usecs)
>  -------------------------------------------------------------------------------
> 
>  -------------------------------------------------------------------------------
>  usemem                          Baseline        zswap        zswap       Change
>  PMD THP                      mm-unstable        store     compress         with
>  BPFTRACE                      10-25-2026     batching     batching     compress
>                                              (patch 6)    (patch 8)     batching
>                                                                             (ns)
>  -------------------------------------------------------------------------------
>  zswap_batch_compress_per_page (ns):            
>                          p50                                 40,086        1,569
>                          p95                                 54,689      -64,505
>                          p99                                 83,248      -88,488
>  -------------------------------------------------------------------------------
>  zswap_single_compress_per_page (ns):
>                          p50       38,517       38,352       36,650       -1,867
>                          p95      119,194      121,174      133,678       14,484
>                          p99      171,736      158,601      169,010       -2,726
>  -------------------------------------------------------------------------------
>  zswap_store_higher_order (ns):
>                          p50   21,012,222   21,322,885   20,176,667     -835,556
>                          p95   25,643,500   26,204,375   24,485,000   -1,158,500
>                          p99   28,567,400   38,577,750   26,158,000   -2,409,400
>  -------------------------------------------------------------------------------
>  zswap_store_order_0 (ns):
>                          p50       37,601       36,994       37,568          -33
>                          p95      123,731      137,034      128,366        4,635
>                          p99      159,965      169,282      175,618       15,653
>  -------------------------------------------------------------------------------
>  vmstat summary:
>  -------------------------------------------------------------------------------
>  zswpin                         1,104,226      993,412    1,091,146       
>  zswpout                        1,688,181    1,582,664    1,669,671       
>  2048kB-alloc                       2,500        2,505        2,500   
>  2048kB-zswpout                     1,535        1,535        1,535   
>  2048kB-swpout-fallback               927          929          875     
>  -------------------------------------------------------------------------------
> 
>  Detailed vmstat & zswap stats after workload finishes:
>  ======================================================
> 
>  ------------------------------------------------------
>  usemem                          Baseline        zswap
>  PMD THP                      mm-unstable     compress
>                                10-25-2026     batching
>                                              (patch 8)
>                                                       
>  ------------------------------------------------------
>  vmstat:
>  ------------------------------------------------------
>  pswpin                               0              0
>  pswpout                              0              0
>  thp_swpout                           0              0
>  thp_swpout_fallback                927            875
>  swpin_zero                           0              0
>  swpout_zero                          0              0
>  zswpin                       1,104,226      1,091,146
>  zswpout                      1,688,181      1,669,671
>  zswpwb                               0              0
>  nrswpin                              0              0
>  nrswpout                             0              0
>  pgmajfault                     173,554        173,774
>  nr_free_pages                1,753,879      1,755,195
>  nr_free_pages_blocks         1,651,712      1,667,072
>  2048kB-alloc                     2,500          2,500
>  2048kB-zswpout                   1,535          1,535
>  2048kB-swpout                        0              0
>  2048kB-swpout-fallback             927            875
>  2048kB-swpin                         0              0
>  memory.current                 352,256        499,712
>  memory.swap.current                  0              0
>  ------------------------------------------------------
>  zswap stats:                                         
>  ------------------------------------------------------
>  pool_limit_hit                       0              0
>  written_back_pages                   0              0
>  reject_alloc_fail                    0              0
>  reject_kmemcache_fail                0              0
>  reject_reclaim_fail                  0              0
>  reject_compress_fail                 0              0
>  reject_compress_poor                 0              0
>  decompress_fail                      0              0
>  stored_incompressible_pages          0              0
>  stored_pages                         0              0
>  pool_total_size                      0              0
>  ------------------------------------------------------

As mentioned in the previous version, I cannot reproduce these results,
mainly because the noise is too high. Digging a bit deeper, it's because
the throttling from memory.high varies. Hacking in a change to make
calculate_high_delay() always return 0 (no memory.high stalls) paints a
clearer picture about throughput improvements from the series up to
patch 6 and patch 8. With that, I see 1-2% improvement in throughput
with patch 6, and almost no improvement with patch 8 on top. Similarly,
for zswap store latency for high-order folios, I see a slight (~1-2%)
improvement with patch 6, but almost none with patch 8 on top.

In order to make meaningful progress, can you send patches 5-6
separately? I assume that 1-4 are prep for 7-8, so 5-6 are standalone. I
also think patch 6 will be simplified if we drop the prep work for
patches 7-8?

Also, PTAL at Sashiko reviews before respinning.