Message ID | 20240103025759.523120-1-21cnbao@gmail.com (mailing list archive) |
---|---|
State | RFC |
Delegated to: | Herbert Xu |
Headers | show |
Series | [RFC,1/2] crypto: introduce acomp_is_async to expose if a acomp has a scomp backend | expand |
>> >> for CPU-based alg, we have completed the compr/decompr within >> crypto_acomp_decompress() >> synchronously. they won't return EINPROGRESS, EBUSY. >> >> The problem is that crypto_acomp won't expose this information to its >> users. if it does, >> we can use this info, we will totally avoid the code of copying >> zsmalloc's data to a tmp >> buffer for the most majority users of zswap. >> >> But I am not sure if we can find a way to convince Herbert(+To) :-) > What would you like to expose? The async status of the underlying > algorithm? Right. followed by a rfc patchset, please help take a look. > > We could certainly do that. But I wonder if it might actually be > better for you to allocate a second sync-only algorithm for such > cases. I'd like to see some real numbers. some hardware might want to use an accelerator to help offload CPU's work. their drivers are working in async mode, for example, hisilicon and intel. I don't have the exact number we can save by removing the redundant memcpy, nor do i have a proper hardware to test and get the number. As Chengming is actually working in zswap, i wonder if you can test my patches and post some data? > > Cheers, > -- > Email: Herbert Xu <herbert@gondor.apana.org.au> Thanks Barry
On Wed, Jan 03, 2024 at 03:57:59PM +1300, Barry Song wrote: > > > We could certainly do that. But I wonder if it might actually be > > better for you to allocate a second sync-only algorithm for such > > cases. I'd like to see some real numbers. > > some hardware might want to use an accelerator to help offload CPU's > work. their drivers are working in async mode, for example, hisilicon > and intel. > > I don't have the exact number we can save by removing the redundant > memcpy, nor do i have a proper hardware to test and get the number. > As Chengming is actually working in zswap, i wonder if you can test > my patches and post some data? I don't have the hardware to test this. Since you're proposing the change, please test it to ensure that we're not adding cruft to the API that's actually detrimental to performance. Thanks,
On Thu, Jan 25, 2024 at 5:41 PM Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Wed, Jan 03, 2024 at 03:57:59PM +1300, Barry Song wrote: > > > > > We could certainly do that. But I wonder if it might actually be > > > better for you to allocate a second sync-only algorithm for such > > > cases. I'd like to see some real numbers. > > > > some hardware might want to use an accelerator to help offload CPU's > > work. their drivers are working in async mode, for example, hisilicon > > and intel. > > > > I don't have the exact number we can save by removing the redundant > > memcpy, nor do i have a proper hardware to test and get the number. > > As Chengming is actually working in zswap, i wonder if you can test > > my patches and post some data? > > I don't have the hardware to test this. Since you're proposing > the change, please test it to ensure that we're not adding cruft > to the API that's actually detrimental to performance. Understood. sorry for the grammatical errors, i was actually asking for chengming's help for testing as he had hardware and was actively working on optimizing zswap. and he has already tested and sent the performance data which I quoted in the formal patchset. > > Thanks, > -- > 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 Thanks Barry
diff --git a/crypto/acompress.c b/crypto/acompress.c index 1c682810a484..99118e879a4a 100644 --- a/crypto/acompress.c +++ b/crypto/acompress.c @@ -152,6 +152,14 @@ struct crypto_acomp *crypto_alloc_acomp_node(const char *alg_name, u32 type, } EXPORT_SYMBOL_GPL(crypto_alloc_acomp_node); +bool acomp_is_async(struct crypto_acomp *acomp) +{ + struct crypto_tfm *tfm = crypto_acomp_tfm(acomp); + + return tfm->__crt_alg->cra_type == &crypto_acomp_type; +} +EXPORT_SYMBOL_GPL(acomp_is_async); + struct acomp_req *acomp_request_alloc(struct crypto_acomp *acomp) { struct crypto_tfm *tfm = crypto_acomp_tfm(acomp); diff --git a/include/crypto/acompress.h b/include/crypto/acompress.h index 574cffc90730..5831080479e9 100644 --- a/include/crypto/acompress.h +++ b/include/crypto/acompress.h @@ -195,6 +195,15 @@ static inline int crypto_has_acomp(const char *alg_name, u32 type, u32 mask) */ struct acomp_req *acomp_request_alloc(struct crypto_acomp *tfm); +/** + * acomp_is_async() -- check if an acomp is asynchronous(can sleep) + * + * @tfm: ACOMPRESS tfm handle allocated with crypto_alloc_acomp() + * + * Return: true if the acomp is asynchronous, otherwise, false + */ +bool acomp_is_async(struct crypto_acomp *tfm); + /** * acomp_request_free() -- zeroize and free asynchronous (de)compression * request as well as the output buffer if allocated