linux-kernel - RE: [PATCH v3] mm/zswap: move to use crypto

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <B926444035E5E2439431908E3842AFD252473C@DGGEMI525-MBS.china.huawei.com>
Date:   Fri, 26 Jun 2020 08:22:00 +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.

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@...dor.apana.org.au> Home Page:
> > http://gondor.apana.org.au/~herbert/
> > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> 
> -barry

Thanks
Barry