| 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
| ||
|
Message-ID: <CAJD7tkZPuMGB4=ULd=znbVqk1LL8oL_gdxi8q-K+vAub33nHgQ@mail.gmail.com>
Date: Tue, 22 Oct 2024 17:48:44 -0700
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Kanchana P Sridhar <kanchana.p.sridhar@...el.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, hannes@...xchg.org,
nphamcs@...il.com, chengming.zhou@...ux.dev, usamaarif642@...il.com,
ryan.roberts@....com, ying.huang@...el.com, 21cnbao@...il.com,
akpm@...ux-foundation.org, linux-crypto@...r.kernel.org,
herbert@...dor.apana.org.au, davem@...emloft.net, clabbe@...libre.com,
ardb@...nel.org, ebiggers@...gle.com, surenb@...gle.com,
kristen.c.accardi@...el.com, zanussi@...nel.org, viro@...iv.linux.org.uk,
brauner@...nel.org, jack@...e.cz, mcgrof@...nel.org, kees@...nel.org,
joel.granados@...nel.org, bfoster@...hat.com, willy@...radead.org,
linux-fsdevel@...r.kernel.org, wajdi.k.feghali@...el.com,
vinodh.gopal@...el.com
Subject: Re: [RFC PATCH v1 04/13] mm: zswap: zswap_compress()/decompress() can
submit, then poll an acomp_req.
On Thu, Oct 17, 2024 at 11:41 PM Kanchana P Sridhar
<kanchana.p.sridhar@...el.com> wrote:
>
> If the crypto_acomp has a poll interface registered, zswap_compress()
> and zswap_decompress() will submit the acomp_req, and then poll() for a
> successful completion/error status in a busy-wait loop. This allows an
> asynchronous way to manage (potentially multiple) acomp_reqs without
> the use of interrupts, which is supported in the iaa_crypto driver.
>
> This enables us to implement batch submission of multiple
> compression/decompression jobs to the Intel IAA hardware accelerator,
> which will process them in parallel; followed by polling the batch's
> acomp_reqs for completion status.
>
> Signed-off-by: Kanchana P Sridhar <kanchana.p.sridhar@...el.com>
> ---
> mm/zswap.c | 51 +++++++++++++++++++++++++++++++++++++++------------
> 1 file changed, 39 insertions(+), 12 deletions(-)
>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index f6316b66fb23..948c9745ee57 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -910,18 +910,34 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry,
> acomp_request_set_params(acomp_ctx->req, &input, &output, PAGE_SIZE, dlen);
>
> /*
> - * it maybe looks a little bit silly that we send an asynchronous request,
> - * then wait for its completion synchronously. This makes the process look
> - * synchronous in fact.
> - * Theoretically, acomp supports users send multiple acomp requests in one
> - * acomp instance, then get those requests done simultaneously. but in this
> - * case, zswap actually does store and load page by page, there is no
> - * existing method to send the second page before the first page is done
> - * in one thread doing zwap.
> - * but in different threads running on different cpu, we have different
> - * acomp instance, so multiple threads can do (de)compression in parallel.
> + * If the crypto_acomp provides an asynchronous poll() interface,
> + * submit the descriptor and poll for a completion status.
> + *
> + * It maybe looks a little bit silly that we send an asynchronous
> + * request, then wait for its completion in a busy-wait poll loop, or,
> + * synchronously. This makes the process look synchronous in fact.
> + * Theoretically, acomp supports users send multiple acomp requests in
> + * one acomp instance, then get those requests done simultaneously.
> + * But in this case, zswap actually does store and load page by page,
> + * there is no existing method to send the second page before the
> + * first page is done in one thread doing zswap.
> + * But in different threads running on different cpu, we have different
> + * acomp instance, so multiple threads can do (de)compression in
> + * parallel.
> */
> - comp_ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req), &acomp_ctx->wait);
> + if (acomp_ctx->acomp->poll) {
> + comp_ret = crypto_acomp_compress(acomp_ctx->req);
> + if (comp_ret == -EINPROGRESS) {
> + do {
> + comp_ret = crypto_acomp_poll(acomp_ctx->req);
> + if (comp_ret && comp_ret != -EAGAIN)
> + break;
> + } while (comp_ret);
> + }
> + } else {
> + comp_ret = crypto_wait_req(crypto_acomp_compress(acomp_ctx->req), &acomp_ctx->wait);
> + }
> +
Is Herbert suggesting that crypto_wait_req(crypto_acomp_compress(..))
essentially do the poll internally for IAA, and hence this change can
be dropped?
> dlen = acomp_ctx->req->dlen;
> if (comp_ret)
> goto unlock;
> @@ -959,6 +975,7 @@ static void zswap_decompress(struct zswap_entry *entry, struct folio *folio)
> struct scatterlist input, output;
> struct crypto_acomp_ctx *acomp_ctx;
> u8 *src;
> + int ret;
>
> acomp_ctx = raw_cpu_ptr(entry->pool->acomp_ctx);
> mutex_lock(&acomp_ctx->mutex);
> @@ -984,7 +1001,17 @@ static void zswap_decompress(struct zswap_entry *entry, struct folio *folio)
> sg_init_table(&output, 1);
> sg_set_folio(&output, folio, PAGE_SIZE, 0);
> acomp_request_set_params(acomp_ctx->req, &input, &output, entry->length, PAGE_SIZE);
> - BUG_ON(crypto_wait_req(crypto_acomp_decompress(acomp_ctx->req), &acomp_ctx->wait));
> + if (acomp_ctx->acomp->poll) {
> + ret = crypto_acomp_decompress(acomp_ctx->req);
> + if (ret == -EINPROGRESS) {
> + do {
> + ret = crypto_acomp_poll(acomp_ctx->req);
> + BUG_ON(ret && ret != -EAGAIN);
> + } while (ret);
> + }
> + } else {
> + BUG_ON(crypto_wait_req(crypto_acomp_decompress(acomp_ctx->req), &acomp_ctx->wait));
> + }
> BUG_ON(acomp_ctx->req->dlen != PAGE_SIZE);
> mutex_unlock(&acomp_ctx->mutex);
>
> --
> 2.27.0
>
Powered by blists - more mailing lists