Re: [PATCH v3 3/3] mm: zswap: use stack requests for synchronous decompression

[Yosry Ahmed]

On Tue, Oct 13, 2026 at 8:11 AM Usama Arif <usama.arif@xxxxxxxxx> wrote:
>
> With separate requests for compression and decompression, loads still
> serialize on the per-CPU decompression mutex. A low-priority load that
> is preempted after the codec drops its stream lock keeps holding the mutex
> and stalls every other load on that CPU, including higher-priority ones.
>
> Synchronous algorithms can use an on-stack request, so decompress with
> one and take no zswap lock. All in-tree software compressors qualify.
> The Crypto API enforces MAX_SYNC_COMP_REQSIZE during initialization,
> so checking acomp_is_async() is sufficient. Asynchronous algorithms
> keep the per-CPU request and mutex, which is still taken before the
> zsmalloc read lock.
>
> Reading the per-CPU context without the mutex is safe. Since
> commit ef3c0f6cb798e ("mm: zswap: tie per-CPU acomp_ctx lifetime to the
> pool"), it is set up before its CPU comes online and is not torn down
> until the pool is destroyed. The codecs keep their own stream locks, and
> crypto_acomp_decompress() rejects on-stack requests only for
> asynchronous transforms, which never take this path.
>
> For software compressors this drops the heap request added for
> decompression. The on-stack request and wait take 216 bytes, which
> makes the load path about 270 bytes deeper on x86-64. Asynchronous
> algorithms pay this too.
>
> Acked-by: Nhat Pham <nphamcs@xxxxxxxxx>
> Signed-off-by: Usama Arif <usama.arif@xxxxxxxxx>

Acked-by: Yosry Ahmed <yosry@xxxxxxxxxx>