[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZbIsuN+bpHNX7CnL@gondor.apana.org.au>
Date: Thu, 25 Jan 2024 17:41:12 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Barry Song <21cnbao@...il.com>
Cc: davem@...emloft.net, akpm@...ux-foundation.org, chriscli@...gle.com,
chrisl@...nel.org, ddstreet@...e.org, hannes@...xchg.org,
linux-mm@...ck.org, nphamcs@...il.com, sjenning@...hat.com,
vitaly.wool@...sulko.com, yosryahmed@...gle.com,
zhouchengming@...edance.com, linux-kernel@...r.kernel.org,
linux-crypto@...r.kernel.org
Subject: Re: [PATCH v4 2/6] mm/zswap: reuse dstmem when decompress
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,
--
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
Powered by blists - more mailing lists