[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <B926444035E5E2439431908E3842AFD25245A6@DGGEMI525-MBS.china.huawei.com>
Date: Fri, 26 Jun 2020 07:54:49 +0000
From: "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linuxarm <linuxarm@...wei.com>,
"Luis Claudio R . Goncalves" <lgoncalv@...hat.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
"David S . Miller" <davem@...emloft.net>,
"Mahipal Challa" <mahipalreddy2006@...il.com>,
Seth Jennings <sjenning@...hat.com>,
"Dan Streetman" <ddstreet@...e.org>,
Vitaly Wool <vitaly.wool@...sulko.com>,
"Wangzhou (B)" <wangzhou1@...ilicon.com>,
Colin Ian King <colin.king@...onical.com>
Subject: RE: [PATCH v3] mm/zswap: move to use crypto_acomp API for hardware
acceleration
> -----Original Message-----
> From: linux-kernel-owner@...r.kernel.org
> [mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of Herbert Xu
> Sent: Friday, June 26, 2020 7:20 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua@...ilicon.com>
> Cc: akpm@...ux-foundation.org; linux-mm@...ck.org;
> linux-kernel@...r.kernel.org; Linuxarm <linuxarm@...wei.com>; Luis Claudio
> R . Goncalves <lgoncalv@...hat.com>; Sebastian Andrzej Siewior
> <bigeasy@...utronix.de>; David S . Miller <davem@...emloft.net>; Mahipal
> Challa <mahipalreddy2006@...il.com>; Seth Jennings
> <sjenning@...hat.com>; Dan Streetman <ddstreet@...e.org>; Vitaly Wool
> <vitaly.wool@...sulko.com>; Wangzhou (B) <wangzhou1@...ilicon.com>;
> Colin Ian King <colin.king@...onical.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.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@...dor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-barry
Powered by blists - more mailing lists