[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240510082850.GC950946@google.com>
Date: Fri, 10 May 2024 17:28:50 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Christoph Hellwig <hch@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Minchan Kim <minchan@...nel.org>, linux-kernel@...r.kernel.org,
linux-block@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
linux-crypto@...r.kernel.org
Subject: Re: [PATCHv3 00/19] zram: convert to custom compression API and
allow algorithms tuning
On (24/05/10 16:12), Herbert Xu wrote:
> On Fri, May 10, 2024 at 05:08:27PM +0900, Sergey Senozhatsky wrote:
> >
> > For some algorithms params needs to be set before ctx is created.
> > For example zstd, crypto/zstd calls zstd_get_params(ZSTD_DEF_LEVEL, 0)
> > to estimate workspace size, which misses the opportunity to configure
> > it an way zram/zswap can benefit from, because those work with PAGE_SIZE
> > source buffer. So for zram zstd_get_params(ZSTD_DEF_LEVEL, PAGE_SIZE)
> > is much better (it saves 1.2MB per ctx, which is per-CPU in zram). Not
> > to mention that zstd_get_params(param->level, 0) is what we need at the
> > end.
>
> For these algorithms where the overhead of allocating a default
> set of parameters and then changing them on a setparam call is
> too high, we could stipulate that the tfm can only be used after
> a setparam call (just as we require a setkey before cipher ops).
OK. I guess for drivers' params support (dictionaries handling etc.)
we take take some code from this series. You mentioned acomp, does this
mean setparam is for async compression only?
Powered by blists - more mailing lists