RE: [PATCH v11 00/24] zswap compression batching with optimized iaa_crypto driver

["Sridhar, Kanchana P" <kanchana.p.sridhar@intel.com>]

> -----Original Message-----
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Sent: Sunday, August 24, 2025 10:39 PM
> To: Sridhar, Kanchana P <kanchana.p.sridhar@intel.com>
> Cc: Nhat Pham <nphamcs@gmail.com>; linux-kernel@vger.kernel.org; linux-
> mm@kvack.org; hannes@cmpxchg.org; yosry.ahmed@linux.dev;
> chengming.zhou@linux.dev; usamaarif642@gmail.com;
> ryan.roberts@arm.com; 21cnbao@gmail.com;
> ying.huang@linux.alibaba.com; akpm@linux-foundation.org;
> senozhatsky@chromium.org; linux-crypto@vger.kernel.org;
> davem@davemloft.net; clabbe@baylibre.com; ardb@kernel.org;
> ebiggers@google.com; surenb@google.com; Accardi, Kristen C
> <kristen.c.accardi@intel.com>; Gomes, Vinicius <vinicius.gomes@intel.com>;
> Feghali, Wajdi K <wajdi.k.feghali@intel.com>; Gopal, Vinodh
> <vinodh.gopal@intel.com>
> Subject: Re: [PATCH v11 00/24] zswap compression batching with optimized
> iaa_crypto driver
> 
> On Fri, Aug 22, 2025 at 07:26:34PM +0000, Sridhar, Kanchana P wrote:
> >
> > 1) The zswap per-CPU acomp_ctx has two sg_tables added, one each for
> >    inputs/outputs, with nents set to the pool->compr_batch_size (1 for
> software
> >    compressors). This per-CPU data incurs additional memory overhead per-
> CPU,
> >    however this is memory that will anyway be allocated on the stack in
> >    zswap_compress(); and less memory overhead than the latter because we
> know
> >    exactly how many sg_table scatterlists to allocate for the given pool
> >    (assuming we don't kmalloc in zswap_compress()). I will make sure to
> quantify
> >    the overhead in v12's commit logs.
> 
> There is no need for any SG lists for the source.  The folio should
> be submitted as the source.
> 
> So only the destination requires an SG list.
> 
> > 6) "For the source, nothing needs to be done because the folio could be
> passed
> >    in as is.". As far as I know, this cannot be accomplished without
> >    modifications to the crypto API for software compressors, because
> compressed
> >    buffers need to be stored in the zswap/zram zs_pools at PAGE_SIZE
> >    granularity.
> 
> Sure.  But all it needs is one central fallback path in the acompress
> API.  I can do this for you.

Thanks Herbert, for reviewing the approach. IIUC, we should follow
these constraints:

1) The folio should be submitted as the source.

2) For the destination, construct an SG list for them and pass that in.
    The rule should be that the SG list must contain a sufficient number
    of pages for the compression output based on the given unit size
    (PAGE_SIZE for zswap).

For PMD folios, there would be 512 compression outputs. In this case,
would we need to pass in an SG list that can contain 512 compression
outputs after calling the acompress API once?

If so, this might not be feasible for zswap since there are only "batch-size"
number of pre-allocated per-CPU output buffers, where "batch_size" is the
max number of pages that can be compressed in one call to the algorithm
(1 for software compressors). Hence, gathering all 512 compression outputs
may not be possible in a single invocation to crypto_acomp_compress().

Is the suggestion to allocate 512 per-CPU output buffers to overcome
this? This could be memory-wise very expensive. Please let me know if
I am missing something.

Thanks for offering to make the necessary changes to the acompress API.
Hoping we can sync on the approach!

Best regards,
Kanchana

> 
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt