> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Herbert Xu
> > Sent: Friday, June 26, 2020 7:20 PM
> > To: Song Bao Hua (Barry Song) <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; Linuxarm <[email protected]>; Luis
> > Claudio R . Goncalves <[email protected]>; Sebastian Andrzej Siewior
> > <[email protected]>; David S . Miller <[email protected]>;
> > Mahipal Challa <[email protected]>; Seth Jennings
> > <[email protected]>; Dan Streetman <[email protected]>; Vitaly Wool
> > <[email protected]>; Wangzhou (B) <[email protected]>;
> > Colin Ian King <[email protected]>
> > 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 <[email protected]> Home Page:
> > http://gondor.apana.org.au/~herbert/
> > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
> -barry
Thanks
Barry
