Re: [PATCH v2 1/2] mm: zswap: use separate compression and decompression requests

[Kanchana P. Sridhar]

On Fri, Oct 9, 2026 at 6:31 PM Usama Arif <usama.arif@xxxxxxxxx> wrote:
>
> Stores and loads serialize on the same per-CPU acomp request and mutex.
> A low-priority store can be preempted as soon as the compressor drops
> its stream lock, while it still holds the mutex. A higher-priority load
> on that CPU then waits until the store runs again, which can take a
> long time when other tasks are runnable.
>
> Give compression and decompression their own request, completion wait
> and mutex. Since commit e2c3b6b21c77f ("mm: zswap: use SG list
> decompression APIs from zsmalloc"), the per-CPU buffer is only used for
> compression, so group it with the compression request. Independent
> requests can share the per-CPU transform; the codecs and drivers
> synchronize their shared state internally. Loads can still wait for
> each other on the decompression mutex, and stores still serialize on
> the compression mutex.
>
> acomp_request_free() ignores NULL requests, so drop the check in
> acomp_ctx_free().
>
> This follows the proposal from Sergey Senozhatsky for the same split
> for zram [1].
>
> [1] https://lore.kernel.org/all/20261005122036.718976-10-senozhatsky@xxxxxxxxxxxx/
>
> Signed-off-by: Usama Arif <usama.arif@xxxxxxxxx>

I have a question with regards to this patch. Is the intent to allow a
decompress thread to run concurrently with a store thread for a given process?
If so, I wonder if incurring context switch/PTE/TLB shootdowns performance
penalty is worth it?

With the proposed change, will zswap_store() continue to run on the "old" CPU
(i.e. the one to which the process got migrated), or is it a requirement that
the "old" process is in sleep state? If so, should we codify/document this
requirement?

On the new CPU, is the same process "runnable", and if so, how do we ensure that
the "higher priority" decompress is handled while the zswap_store() prior to
preemption is still not done?

Thanks,
Kanchana