linux-kernel - Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for compress/decompress batching.

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJD7tkaTuNWF42+CoCLruPZks3F7H9mS=6S74cmXnyWz-2tuPw@mail.gmail.com>
Date: Mon, 6 Jan 2025 19:10:53 -0800
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: "Sridhar, Kanchana P" <kanchana.p.sridhar@...el.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, 
	"hannes@...xchg.org" <hannes@...xchg.org>, "nphamcs@...il.com" <nphamcs@...il.com>, 
	"chengming.zhou@...ux.dev" <chengming.zhou@...ux.dev>, 
	"usamaarif642@...il.com" <usamaarif642@...il.com>, "ryan.roberts@....com" <ryan.roberts@....com>, 
	"21cnbao@...il.com" <21cnbao@...il.com>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, 
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>, "davem@...emloft.net" <davem@...emloft.net>, 
	"clabbe@...libre.com" <clabbe@...libre.com>, "ardb@...nel.org" <ardb@...nel.org>, 
	"ebiggers@...gle.com" <ebiggers@...gle.com>, "surenb@...gle.com" <surenb@...gle.com>, 
	"Accardi, Kristen C" <kristen.c.accardi@...el.com>, 
	"Feghali, Wajdi K" <wajdi.k.feghali@...el.com>, "Gopal, Vinodh" <vinodh.gopal@...el.com>
Subject: Re: [PATCH v5 02/12] crypto: acomp - Define new interfaces for
 compress/decompress batching.

On Mon, Jan 6, 2025 at 6:06 PM Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> On Mon, Jan 06, 2025 at 05:46:01PM -0800, Yosry Ahmed wrote:
> >
> > For software compressors, the batch size should be 1. In that
> > scenario, from a zswap perspective (without going into the acomp
> > implementation details please), is there a functional difference? If
> > not, we can just use the request chaining API regardless of batching
> > if that is what Herbert means.
>
> If you can supply a batch size of 8 for iaa, there is no reason
> why you can't do it for software algorithms.  It's the same
> reason that we have GSO in the TCP stack, regardless of whether
> the hardware can handle TSO.

The main problem is memory usage. Zswap needs a PAGE_SIZE*2-sized
buffer for each request on each CPU. We preallocate these buffers to
avoid trying to allocate this much memory in the reclaim path (i.e.
potentially allocating two pages to reclaim one).

With batching, we need to preallocate N PAGE_SIZE*2-sized buffers on
each CPU instead. For N=8, we are allocating PAGE_SIZE*14 extra memory
on each CPU (56 KB on x86). That cost may be acceptable with IAA
hardware accelerated batching, but not for software compressors that
will end up processing the batch serially anyway.

Does this make sense to you or did I miss something?

>
> The amortisation of the segmentation cost means that it will be
> a win over-all.
>
> 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
>