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

From: Song Bao Hua (Barry Song)
Date: Fri Jun 26 2020 - 04:22:20 EST


> > -----Original Message-----
> > From: linux-kernel-owner@xxxxxxxxxxxxxxx
> > [mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of Herbert Xu
> > Sent: Friday, June 26, 2020 7:20 PM
> > To: Song Bao Hua (Barry Song) <song.bao.hua@xxxxxxxxxxxxx>
> > Cc: akpm@xxxxxxxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx;
> > linux-kernel@xxxxxxxxxxxxxxx; Linuxarm <linuxarm@xxxxxxxxxx>; Luis
> > Claudio R . Goncalves <lgoncalv@xxxxxxxxxx>; Sebastian Andrzej Siewior
> > <bigeasy@xxxxxxxxxxxxx>; David S . Miller <davem@xxxxxxxxxxxxx>;
> > Mahipal Challa <mahipalreddy2006@xxxxxxxxx>; Seth Jennings
> > <sjenning@xxxxxxxxxx>; Dan Streetman <ddstreet@xxxxxxxx>; Vitaly Wool
> > <vitaly.wool@xxxxxxxxxxxx>; Wangzhou (B) <wangzhou1@xxxxxxxxxxxxx>;
> > Colin Ian King <colin.king@xxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxxxxx> Home Page:
> > http://gondor.apana.org.au/~herbert/
> > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
> -barry

Thanks
Barry