All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org, "Daniel P . Berrangé" <berrange@redhat.com>
Subject: Re: [PATCH] migration: Remove RDMA_UNREGISTRATION_EXAMPLE
Date: Mon, 20 Jun 2022 18:30:11 +0100	[thread overview]
Message-ID: <YrCuoxF6iPWQxh4q@work-vm> (raw)
In-Reply-To: <20220620150918.57471-1-quintela@redhat.com>

* Juan Quintela (quintela@redhat.com) wrote:
> Nobody has ever showed up to unregister individual pages, and another
> set of patches written by Daniel P. Berrangé <berrange@redhat.com>
> just remove qemu_rdma_signal_unregister() function needed here.
> 
> Signed-off-by: Juan Quintela <quintela@redhat.com>

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

> ---
>  migration/rdma.c | 41 -----------------------------------------
>  1 file changed, 41 deletions(-)
> 
> diff --git a/migration/rdma.c b/migration/rdma.c
> index 672d1958a9..8504152f39 100644
> --- a/migration/rdma.c
> +++ b/migration/rdma.c
> @@ -1370,30 +1370,6 @@ const char *print_wrid(int wrid)
>      return wrid_desc[wrid];
>  }
>  
> -/*
> - * RDMA requires memory registration (mlock/pinning), but this is not good for
> - * overcommitment.
> - *
> - * In preparation for the future where LRU information or workload-specific
> - * writable writable working set memory access behavior is available to QEMU
> - * it would be nice to have in place the ability to UN-register/UN-pin
> - * particular memory regions from the RDMA hardware when it is determine that
> - * those regions of memory will likely not be accessed again in the near future.
> - *
> - * While we do not yet have such information right now, the following
> - * compile-time option allows us to perform a non-optimized version of this
> - * behavior.
> - *
> - * By uncommenting this option, you will cause *all* RDMA transfers to be
> - * unregistered immediately after the transfer completes on both sides of the
> - * connection. This has no effect in 'rdma-pin-all' mode, only regular mode.
> - *
> - * This will have a terrible impact on migration performance, so until future
> - * workload information or LRU information is available, do not attempt to use
> - * this feature except for basic testing.
> - */
> -/* #define RDMA_UNREGISTRATION_EXAMPLE */
> -
>  /*
>   * Perform a non-optimized memory unregistration after every transfer
>   * for demonstration purposes, only if pin-all is not requested.
> @@ -1571,18 +1547,6 @@ static uint64_t qemu_rdma_poll(RDMAContext *rdma, struct ibv_cq *cq,
>          if (rdma->nb_sent > 0) {
>              rdma->nb_sent--;
>          }
> -
> -        if (!rdma->pin_all) {
> -            /*
> -             * FYI: If one wanted to signal a specific chunk to be unregistered
> -             * using LRU or workload-specific information, this is the function
> -             * you would call to do so. That chunk would then get asynchronously
> -             * unregistered later.
> -             */
> -#ifdef RDMA_UNREGISTRATION_EXAMPLE
> -            qemu_rdma_signal_unregister(rdma, index, chunk, wc.wr_id);
> -#endif
> -        }
>      } else {
>          trace_qemu_rdma_poll_other(print_wrid(wr_id), wr_id, rdma->nb_sent);
>      }
> @@ -2137,11 +2101,6 @@ retry:
>  
>      chunk_end = ram_chunk_end(block, chunk + chunks);
>  
> -    if (!rdma->pin_all) {
> -#ifdef RDMA_UNREGISTRATION_EXAMPLE
> -        qemu_rdma_unregister_waiting(rdma);
> -#endif
> -    }
>  
>      while (test_bit(chunk, block->transit_bitmap)) {
>          (void)count;
> -- 
> 2.35.3
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



      reply	other threads:[~2022-06-20 17:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20 15:09 [PATCH] migration: Remove RDMA_UNREGISTRATION_EXAMPLE Juan Quintela
2022-06-20 17:30 ` Dr. David Alan Gilbert [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YrCuoxF6iPWQxh4q@work-vm \
    --to=dgilbert@redhat.com \
    --cc=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.