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

[Yosry Ahmed <yosry@kernel.org>]

On Thu, Nov 05, 2026 at 11:24:04PM -0800, Kanchana P. Sridhar wrote:
>  =============================================================================
>    usemem PMD THP BPFTRACE
>  =============================================================================
>            Baseline           zswap           zswap          Change    Change
>         mm-unstable           store        compress            with      with
>          10-25-2026        batching        batching        compress  compress
>                         (patch 6-7)       (patch 8)        batching  batching
>                                                                (ns)       %
>  =============================================================================
>   zswap_store_order0_folio (ns):
>  =============================================================================
>   p50        39,631          37,538          37,765          -1,866    -4.71% 
>   p95        53,088          49,690          49,349          -3,739    -7.04% 
>   p99        65,065          63,529          57,404          -7,661   -11.77%
>  =============================================================================
>   zswap_store_higher_order_folio (ns):
>  =============================================================================
>   p50    21,460,366      21,201,411      20,383,233      -1,077,133    -5.02%
>   p95    25,975,341      27,558,253      25,045,350        -929,991    -3.58%
>   p99    29,538,493      61,926,648      27,184,835      -2,353,658    -7.97%
>  =============================================================================
>   zswap_single_compress_per_page (ns):
>  =============================================================================
>   p50        37,545          39,320          37,218            -327    -0.87%
>   p95        51,549          66,503          51,481             -68    -0.13%
>   p99        89,866         134,854          87,091          -2,775    -3.09%
>  =============================================================================
>   zswap_batch_compress_per_page (ns):            
>  =============================================================================
>   p50                                        40,493           2,948     7.85%
>   p95                                        56,944           5,395    10.47%
>   p99                                        76,242         -13,624   -15.16%
>  =============================================================================

As with previous versions, I cannot reproduce these results. I tried
with a QEMU VM on a Cascade Lake host. I saw marginal improvements with
patch 6 and no significant gain with patches 7-8.

I noticed that you omitted high-level metrics (e.g. throughput), I
didn't see significant changes in throughput, and I also ran a kernel
build and saw a small regression in some cases (probably with order-0
folios) and no significant improvement otherwise. Even if latency for
some functions does improve slightly, it doesn't matter if it doesn't
show up on higher-level metrics.

It could be the difference in setups, or the overhead of bpftrace hooks
for zswap_compress() might affect measured zswap_store() latencies, as
you will have fewer zswap_compress() calls with patch 8.

As advised previously, I would trim down patch 6 to the bare minimum
(without all the scaffolding and prep work for patches 7-8), and send it
separately (with patch 5), and we can check if it's worth adding, I am
still concerned it might be adding overhead for order-0 to be honest.

I am questioning the benefit of batching here without HW batching, so
far the results are more concerning than encouraging. I already spent
too much time trying to reproduce the performance gains. Also, sending
new versions without resolving discussions on previous ones is not
really productive.