lkml.org 
[lkml]   [2020]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v3] mm/zswap: move to use crypto_acomp API for hardware acceleration
Date
> > -----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

\
 
 \ /
  Last update: 2020-06-26 10:23    [W:0.036 / U:4.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site