On Thu, Feb 22, 2024 at 09:11:33PM +1300, Barry Song wrote:
> From: Barry Song <[email protected]>
>
> In zswap, if we use zsmalloc, we cannot sleep while we map the
> compressed memory, so we copy it to a temporary buffer. By
> knowing the alg won't sleep can help zswap to avoid the
> memcpy.
> Thus we introduce an API in crypto to expose if acomp is async,
> and zswap can use it to decide if it can remove copying to the
> tmp buffer.
>
> -v6:
> * add acked-by of Herbert, Thanks!
> * remove patch 3/3 from the series, as that one will go
> through crypto
>
> Barry Song (2):
> crypto: introduce: acomp_is_async to expose if comp drivers might
> sleep
> mm/zswap: remove the memcpy if acomp is not sleepable
>
> include/crypto/acompress.h | 6 ++++++
> mm/zswap.c | 6 ++++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
Acked-by: Johannes Weiner <[email protected]>
Looks good to me.
One small question: why cache is_sleepable in zswap instead of
checking acomp_is_async() directly? It doesn't look expensive.
On Fri, Mar 8, 2024 at 8:11 PM Johannes Weiner <[email protected]> wrote:
>
> On Thu, Feb 22, 2024 at 09:11:33PM +1300, Barry Song wrote:
> > From: Barry Song <[email protected]>
> >
> > In zswap, if we use zsmalloc, we cannot sleep while we map the
> > compressed memory, so we copy it to a temporary buffer. By
> > knowing the alg won't sleep can help zswap to avoid the
> > memcpy.
> > Thus we introduce an API in crypto to expose if acomp is async,
> > and zswap can use it to decide if it can remove copying to the
> > tmp buffer.
> >
> > -v6:
> > * add acked-by of Herbert, Thanks!
> > * remove patch 3/3 from the series, as that one will go
> > through crypto
> >
> > Barry Song (2):
> > crypto: introduce: acomp_is_async to expose if comp drivers might
> > sleep
> > mm/zswap: remove the memcpy if acomp is not sleepable
> >
> > include/crypto/acompress.h | 6 ++++++
> > mm/zswap.c | 6 ++++--
> > 2 files changed, 10 insertions(+), 2 deletions(-)
>
> Acked-by: Johannes Weiner <[email protected]>
>
> Looks good to me.
>
> One small question: why cache is_sleepable in zswap instead of
> checking acomp_is_async() directly? It doesn't look expensive.
Thank you, Johannes. Your question sparked an idea for me. Drivers, such as
drivers/crypto/intel/iaa/iaa_crypto_main.c, have the capability to dynamically
switch between synchronous and asynchronous modes. Consequently, they
also have the opportunity to dynamically modify cra_flags. This means that
we may not require the cache. right now, iaa always has an ASYNC flag and
needs a memcpy. If we can dynamically change the flag, the iaa platform might
be able to further remove a memcpy in zswap if sync mode is set for it.
/*
* The iaa crypto driver supports three 'sync' methods determining how
* compressions and decompressions are performed:
*
* - sync: the compression or decompression completes before
* returning. This is the mode used by the async crypto
* interface when the sync mode is set to 'sync' and by
* the sync crypto interface regardless of setting.
*
* - async: the compression or decompression is submitted and returns
* immediately. Completion interrupts are not used so
* the caller is responsible for polling the descriptor
* for completion. This mode is applicable to only the
* async crypto interface and is ignored for anything
* else.
*
* - async_irq: the compression or decompression is submitted and
* returns immediately. Completion interrupts are
* enabled so the caller can wait for the completion and
* yield to other threads. When the compression or
* decompression completes, the completion is signaled
* and the caller awakened. This mode is applicable to
* only the async crypto interface and is ignored for
* anything else.
*
* These modes can be set using the iaa_crypto sync_mode driver
* attribute.
*/
But it seems we will get lots of synchronized issues particularly when we are
changing the mode by sysfs.
static ssize_t sync_mode_store(struct device_driver *driver,
const char *buf, size_t count)
{
...
}
I don't have any iaa hardware. But I'd like to ask if this can interest Tom, the
maintainer of INTEL IAA CRYPTO DRIVER to have a go :-)
+Tom Zanussi
Thanks
Barry