Received-SPF: pass (google.com: domain of linux-kernel+bounces-107436-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240222081135.173040-1-21cnbao@gmail.com> <20240308121139.GA116548@cmpxchg.org>
In-Reply-To: <20240308121139.GA116548@cmpxchg.org>
From: Barry Song <21cnbao@gmail.com>
Date: Tue, 19 Mar 2024 19:00:55 +0800
Message-ID: <CAGsJ_4wSSvVxPb7eJqewqM1My7y+yT1hNZC0s04G=mD06tq4=g@mail.gmail.com>
Subject: Re: [PATCH v6 0/2] zswap: remove the memcpy if acomp is not sleepable
To: Johannes Weiner <hannes@cmpxchg.org>, Tom Zanussi <tom.zanussi@linux.intel.com>, 
	herbert@gondor.apana.org.au
Cc: akpm@linux-foundation.org, davem@davemloft.net, 
	linux-crypto@vger.kernel.org, linux-mm@kvack.org, nphamcs@gmail.com, 
	yosryahmed@google.com, zhouchengming@bytedance.com, chriscli@google.com, 
	chrisl@kernel.org, ddstreet@ieee.org, linux-kernel@vger.kernel.org, 
	sjenning@redhat.com, vitaly.wool@konsulko.com, 
	Barry Song <v-songbaohua@oppo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 8, 2024 at 8:11=E2=80=AFPM Johannes Weiner <hannes@cmpxchg.org>=
 wrote:
>
> On Thu, Feb 22, 2024 at 09:11:33PM +1300, Barry Song wrote:
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > 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 <hannes@cmpxchg.org>
>
> 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 dynamica=
lly
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 mig=
ht
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 a=
re
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