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

[Kanchana P. Sridhar]

On Thu, Oct 15, 2026 at 3:04 PM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> On Thu, Oct 15, 2026 at 3:00 PM Kanchana P. Sridhar
> <kanchanapsridhar2026@xxxxxxxxx> wrote:
> >
> > On Wed, Oct 14, 2026 at 8:45 AM Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Oct 08, 2026 at 11:28:06AM -0700, Kanchana P. Sridhar 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:
> > > > ==============================================
> > >
> > > How much of the performance benefits come from patch 6 vs patch 8?
> >
> > This is how the performance changes: Average throughput is averaged
> > from 10 iterations of usemem.
> >
> > patch 6: 19,119 KB/s
> > patch 8: 17,593 KB/s
> >
> > So the acomp_do_req_chain() path that ZSTD goes through with patch 8
> > causes a regression, even though it provides a generic batching
> > framework in acomp.
> >
> > I was able to retrieve performance with the following change in acompress.c:
>
> Why add it to begin with in this case?

Patch 3 ("crypto: acomp - Add trivial segmentation wrapper.") was
co-developed with Herbert. The request chaining for non-segmentation
algorithms was as in Herbert's original implementation. Since this
causes a regression, I would like to get Herbert's Ok on replacing the
request chaining in this part of crypto_acomp_compress().

>
> >
> > patch 3 with this change in acompress.c: 19,578 KB/s
> >
> > diff --git a/crypto/acompress.c b/crypto/acompress.c
> > index 192ea996e779..dc609bd7d927 100644
> > --- a/crypto/acompress.c
> > +++ b/crypto/acompress.c
> > @@ -293,8 +293,12 @@ int crypto_acomp_compress(struct acomp_req *req)
> >                 return -EAGAIN;
> >
> >         if (likely(req->unit_size && acomp_request_issg(req))) {
> > -               if (!crypto_acomp_req_seg(tfm))
> > -                       return acomp_do_req_chain(req, true);
> > +               if (!crypto_acomp_req_seg(tfm)) {
> > +                       int err = tfm->compress(req);
> > +
> > +                       req->dst->length = unlikely(err) ? err : req->dlen;
> > +                       return err;
> > +               }
> >
> >                 return tfm->compress(req);
> >         }
> >
> > Herbert, would you be Ok with this change in patch 3?