All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: mrhines@linux.vnet.ibm.com
Cc: aliguori@us.ibm.com, quintela@redhat.com, qemu-devel@nongnu.org,
	owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com,
	gokul@us.ibm.com, chegu_vinod@hp.com, knoel@redhat.com
Subject: Re: [Qemu-devel] [PATCH 3/6] rdma: core logic
Date: Fri, 28 Jun 2013 09:33:19 +0200	[thread overview]
Message-ID: <51CD3C3F.6080207@redhat.com> (raw)
In-Reply-To: <1372373098-5877-4-git-send-email-mrhines@linux.vnet.ibm.com>

Il 28/06/2013 00:44, mrhines@linux.vnet.ibm.com ha scritto:
> + *
> + * 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_ALLOW_REGISTRATION_WINDOW

Out of curiosity, how terrible is the terrible impact?

> + * Perform a non-optimized memory registration after every transfer
> + * for demonsration purposes, only if pin-all is not requested.
> + */
> +static int qemu_rdma_unregister_waiting(RDMAContext *rdma) {
> +#ifdef RDMA_ALLOW_REGISTRATION_WINDOW

IIRC  function can be always enabled, it will just do nothing if
no one registers anything.  It is just this bit that needs the
#ifdef:

+
+        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_ALLOW_REGISTRATION_WINDOW
+            qemu_rdma_signal_unregister(rdma, index, chunk, wc.wr_id);
   >> #endif
+        }

Then qemu_rdma_signal_unregister would be unused for
!RDMA_ALLOW_REGISTRATION_WINDOW, so you would need to put that
function within an #ifdef (the whole function, not just the
body).

At this point RDMA_ALLOW_REGISTRATION_WINDOW becomes a slightly
wrong name.  What about RDMA_UNREGISTRATION_EXAMPLE?

> 
> +        if(test_bit(chunk, block->transit_bitmap)) {
> +            DDPRINTF("Cannot unregister inflight chunk: %" PRIu64 "\n", chunk);
> +            continue;
> +        }

Nobody will process this unregistration after this.  Should you move this

+        // perhaps test_and_clear_bit here?  and exit if the bit is zero
+        clear_bit(chunk, block->unregister_bitmap);
+
+        ret = ibv_dereg_mr(block->pmr[chunk]);
+        block->pmr[chunk] = NULL;
+        block->remote_keys[chunk] = 0;
+
+        if(ret != 0) {
+            perror("unregistration chunk failed");
+            return -ret;
+        }
+        rdma->total_registrations--;
+
+        reg.key.chunk = chunk;
+        ret = qemu_rdma_exchange_send(rdma, &head, (uint8_t *) &reg,
+                                &resp, &resp_idx, NULL);
+        if (ret < 0) {
+            return ret;
+        }
+
+        DDPRINTF("Unregister for chunk: %" PRIu64 " complete.\n", chunk);

to a separate function and check the unregister_bitmap when you get a
transfer completed message from IB?

Also, you do not need to receive the unregistration completed response
now, do you?  You can have another bitmap for "unregistration in progress"
and only wait for completion before re-pinning.  This way, the impact
of unregistration is low if the page is not going to be changed soon.

_However_, please make this new functionality a separate patch so that we
can discuss it better.

Paolo

  parent reply	other threads:[~2013-06-28  7:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27 22:44 [Qemu-devel] [PATCH 0/6] rdma: core logic and unpin support mrhines
2013-06-27 22:44 ` [Qemu-devel] [PATCH 1/6] rdma: update documentation to reflect new " mrhines
2013-06-27 23:09   ` Eric Blake
2013-06-28 13:17     ` Michael R. Hines
2013-06-27 22:44 ` [Qemu-devel] [PATCH 2/6] rdma: introduce ram_handle_compressed() mrhines
2013-06-27 22:56   ` Peter Maydell
2013-06-28  7:17     ` Paolo Bonzini
2013-06-27 22:44 ` [Qemu-devel] [PATCH 3/6] rdma: core logic mrhines
2013-06-27 23:16   ` Peter Maydell
2013-06-28 13:23     ` Michael R. Hines
2013-06-28 13:28       ` Peter Maydell
2013-06-28 14:00         ` Michael R. Hines
2013-06-28 14:07           ` Peter Maydell
2013-06-28 14:22             ` Michael R. Hines
2013-06-28  7:33   ` Paolo Bonzini [this message]
2013-06-28 14:11     ` Michael R. Hines
2013-06-27 22:44 ` [Qemu-devel] [PATCH 4/6] rdma: allow state transitions between other states besides ACTIVE mrhines
2013-06-27 23:10   ` Eric Blake
2013-06-28  7:34     ` Paolo Bonzini
2013-06-27 22:44 ` [Qemu-devel] [PATCH 5/6] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition mrhines
2013-06-27 22:44 ` [Qemu-devel] [PATCH 6/6] rdma: account for the time spent in MIG_STATE_SETUP through QMP mrhines

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=51CD3C3F.6080207@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=abali@us.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=chegu_vinod@hp.com \
    --cc=gokul@us.ibm.com \
    --cc=knoel@redhat.com \
    --cc=mrhines@linux.vnet.ibm.com \
    --cc=mrhines@us.ibm.com \
    --cc=owasserm@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.