Re: [PATCH v14 00/26] zswap compression batching with optimized iaa_crypto driver

[Andrew Morton]

On Wed, 4 Feb 2026 18:21:43 +0000 Yosry Ahmed <yosry.ahmed@xxxxxxxxx> wrote:

> On Sat, Jan 24, 2026 at 07:35:11PM -0800, Kanchana P Sridhar wrote:
> [..] 
> 
> I think this series is really hard to move and respin in its current
> form.
> 
> Herbert, could we take in the crypto patches separately (if they are
> ready)? Not sure if it's better to take them through the crypto tree
> (and provide a tag for Andrew?), or through the mm tree.

Keeping everything in the same tree is of course simpler.

> But either way,
> most review is on the later zswap patches and respinning all these
> crypto patch every time is a pain.

It's mainly a crypto patchset by linecount:

:  .../driver-api/crypto/iaa/iaa-crypto.rst      |  168 +-
:  crypto/acompress.c                            |  110 +-
:  crypto/testmgr.c                              |   10 +
:  crypto/testmgr.h                              |   74 +
:  drivers/crypto/intel/iaa/Makefile             |    4 +-
:  drivers/crypto/intel/iaa/iaa_crypto.h         |   95 +-
:  .../intel/iaa/iaa_crypto_comp_dynamic.c       |   22 +
:  drivers/crypto/intel/iaa/iaa_crypto_main.c    | 2926 ++++++++++++-----
:  drivers/crypto/intel/iaa/iaa_crypto_stats.c   |    8 +
:  drivers/crypto/intel/iaa/iaa_crypto_stats.h   |    2 +
:  include/crypto/acompress.h                    |   68 +
:  include/crypto/algapi.h                       |    5 +
:  include/crypto/internal/acompress.h           |   15 +
:  include/linux/crypto.h                        |    3 +
:  mm/zswap.c                                    |  724 ++--
:  15 files changed, 3144 insertions(+), 1090 deletions(-)
:  create mode 100644 drivers/crypto/intel/iaa/iaa_crypto_comp_dynamic.c

So I expect it'll work to take all this into the crypto tree.

> >   mm: zswap: Tie per-CPU acomp_ctx lifetime to the pool.
> >   mm: zswap: Consistently use IS_ERR_OR_NULL() to check acomp_ctx
> >     resources.
> 
> Andrew, I think this two zswap patches are in good shape, and are
> standalone improvements. Do they apply to mm-unstable? Could we take
> them in separately to lighten the load of respinning this?

"mm: zswap: Tie per-CPU acomp_ctx lifetime to the pool" throws a few
rejects.

"mm: zswap: Consistently use IS_ERR_OR_NULL() to check acomp_ctx
resources" also throws rejects when applied standalone.