RE: [PATCH v3] mm/zswap: move to use crypto_acomp API for hardware acceleration

["Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>]

> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org
> > [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Herbert Xu
> > Sent: Friday, June 26, 2020 7:20 PM
> > To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> > Cc: akpm@linux-foundation.org; linux-mm@kvack.org;
> > linux-kernel@vger.kernel.org; Linuxarm <linuxarm@huawei.com>; Luis
> > Claudio R . Goncalves <lgoncalv@redhat.com>; Sebastian Andrzej Siewior
> > <bigeasy@linutronix.de>; David S . Miller <davem@davemloft.net>;
> > Mahipal Challa <mahipalreddy2006@gmail.com>; Seth Jennings
> > <sjenning@redhat.com>; Dan Streetman <ddstreet@ieee.org>; Vitaly Wool
> > <vitaly.wool@konsulko.com>; Wangzhou (B) <wangzhou1@hisilicon.com>;
> > Colin Ian King <colin.king@canonical.com>
> > Subject: Re: [PATCH v3] mm/zswap: move to use crypto_acomp API for
> > hardware acceleration
> >
> > On Fri, Jun 26, 2020 at 07:09:03PM +1200, Barry Song wrote:
> > >
> > > +	mutex_lock(&acomp_ctx->mutex);
> > > +
> > > +	src = kmap(page);
> > > +	dst = acomp_ctx->dstmem;
> > > +	sg_init_one(&input, src, PAGE_SIZE);
> > > +	/* zswap_dstmem is of size (PAGE_SIZE * 2). Reflect same in sg_list */
> > > +	sg_init_one(&output, dst, PAGE_SIZE * 2);
> > > +	acomp_request_set_params(acomp_ctx->req, &input, &output,
> > PAGE_SIZE, dlen);
> > > +	ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req),
> > &acomp_ctx->wait);
> > > +	dlen = acomp_ctx->req->dlen;
> > > +	kunmap(page);
> >
> > Waiting on an async request like this is just silly.  This defeats the
> > whole purpose of having a fallback.
> 
> For this zswap case and for this moment, it is probably not.
> As for this case, there are no two parallel (de)compressions which can be done
> in parallel in a single (de)compressor instance.
> The original zswap code is doing all compression/decompression in atomic
> context.
> Right now, to use acomp api, the patch has moved to sleep-able context.
> 
> However, compression/decompression can be done in parallel in different
> instances of acomp, also different cpus.
> 
> If we want to do multiple (de)compressions simultaneously in one acomp
> instance by callbacks, it will ask a large changes in zswap.c not only using the
> new APIs. I think we can only achieve the ideal goal step by step.

On the other hand, I also don't think mm/frontswap.c supports async store. It is pretty much
a sync operation to call store callback of frontswap for every single page:

int __frontswap_store(struct page *page)
{
	...
	/* Try to store in each implementation, until one succeeds. */
	for_each_frontswap_ops(ops) {
		ret = ops->store(type, offset, page);
		if (!ret) /* successful store */
			break;
	}
	...
	if (frontswap_writethrough_enabled)
		/* report failure so swap also writes to swap device */
		ret = -1;
	return ret;
}

If we don't want to execute a sync wait in zswap, a lot of things need changes, not only zswap.

> 
> >
> > Cheers,
> > --
> > Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page:
> > http://gondor.apana.org.au/~herbert/
> > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> 
> -barry

Thanks
Barry