From: "Michael R. Hines" <mrhines@linux.vnet.ibm.com>
To: "Dr. David Alan Gilbert (git)" <dgilbert@redhat.com>,
qemu-devel@nongnu.org
Cc: amit.shah@redhat.com, arei.gonglei@huawei.com,
mrhines@us.ibm.com, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 08/12] Allow rdma_delete_block to work without the hash
Date: Thu, 11 Jun 2015 13:36:35 -0500 [thread overview]
Message-ID: <5579D533.9070608@linux.vnet.ibm.com> (raw)
In-Reply-To: <1434043048-4444-9-git-send-email-dgilbert@redhat.com>
On 06/11/2015 12:17 PM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>
> In the next patch we remove the hash on the destination,
> rdma_delete_block does two things with the hash which can be avoided:
> a) The caller passes the offset and rdma_delete_block looks it up
> in the hash; fixed by getting the caller to pass the block
> b) The hash gets recreated after deletion; fixed by making that
> conditional on the hash being initialised.
>
> While this function is currently only used during cleanup, Michael
> asked that we keep it general for future dynamic block registration
> work.
>
> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> ---
> migration/rdma.c | 27 ++++++++++++++++-----------
> trace-events | 2 +-
> 2 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/migration/rdma.c b/migration/rdma.c
> index 396329c..8d99378 100644
> --- a/migration/rdma.c
> +++ b/migration/rdma.c
> @@ -617,16 +617,19 @@ static int qemu_rdma_init_ram_blocks(RDMAContext *rdma)
> return 0;
> }
>
> -static int rdma_delete_block(RDMAContext *rdma, ram_addr_t block_offset)
> +/*
> + * Note: If used outside of cleanup, the caller must ensure that the destination
> + * block structures are also updated
> + */
> +static int rdma_delete_block(RDMAContext *rdma, RDMALocalBlock *block)
> {
> RDMALocalBlocks *local = &rdma->local_ram_blocks;
> - RDMALocalBlock *block = g_hash_table_lookup(rdma->blockmap,
> - (void *) block_offset);
> RDMALocalBlock *old = local->block;
> int x;
>
> - assert(block);
> -
> + if (rdma->blockmap) {
> + g_hash_table_remove(rdma->blockmap, (void *)(uintptr_t)block->offset);
> + }
> if (block->pmr) {
> int j;
>
> @@ -659,8 +662,11 @@ static int rdma_delete_block(RDMAContext *rdma, ram_addr_t block_offset)
> g_free(block->block_name);
> block->block_name = NULL;
>
> - for (x = 0; x < local->nb_blocks; x++) {
> - g_hash_table_remove(rdma->blockmap, (void *)(uintptr_t)old[x].offset);
> + if (rdma->blockmap) {
> + for (x = 0; x < local->nb_blocks; x++) {
> + g_hash_table_remove(rdma->blockmap,
> + (void *)(uintptr_t)old[x].offset);
> + }
> }
>
> if (local->nb_blocks > 1) {
> @@ -682,8 +688,7 @@ static int rdma_delete_block(RDMAContext *rdma, ram_addr_t block_offset)
> local->block = NULL;
> }
>
> - trace_rdma_delete_block(local->nb_blocks,
> - (uintptr_t)block->local_host_addr,
> + trace_rdma_delete_block(block, (uintptr_t)block->local_host_addr,
> block->offset, block->length,
> (uintptr_t)(block->local_host_addr + block->length),
> BITS_TO_LONGS(block->nb_chunks) *
> @@ -693,7 +698,7 @@ static int rdma_delete_block(RDMAContext *rdma, ram_addr_t block_offset)
>
> local->nb_blocks--;
>
> - if (local->nb_blocks) {
> + if (local->nb_blocks && rdma->blockmap) {
> for (x = 0; x < local->nb_blocks; x++) {
> g_hash_table_insert(rdma->blockmap,
> (void *)(uintptr_t)local->block[x].offset,
> @@ -2214,7 +2219,7 @@ static void qemu_rdma_cleanup(RDMAContext *rdma)
>
> if (rdma->local_ram_blocks.block) {
> while (rdma->local_ram_blocks.nb_blocks) {
> - rdma_delete_block(rdma, rdma->local_ram_blocks.block->offset);
> + rdma_delete_block(rdma, &rdma->local_ram_blocks.block[0]);
> }
> }
Looks good overall. Maybe this is a silly question, but have you done
a few migrations over actual RDMA hardware yet?
Reviewed-by: Michael R. Hines <mrhines@us.ibm.com>
> diff --git a/trace-events b/trace-events
> index 0f37a4b..7dff362 100644
> --- a/trace-events
> +++ b/trace-events
> @@ -1452,7 +1452,7 @@ qemu_rdma_write_one_sendreg(uint64_t chunk, int len, int index, int64_t offset)
> qemu_rdma_write_one_top(uint64_t chunks, uint64_t size) "Writing %" PRIu64 " chunks, (%" PRIu64 " MB)"
> qemu_rdma_write_one_zero(uint64_t chunk, int len, int index, int64_t offset) "Entire chunk is zero, sending compress: %" PRIu64 " for %d bytes, index: %d, offset: %" PRId64
> rdma_add_block(const char *block_name, int block, uint64_t addr, uint64_t offset, uint64_t len, uint64_t end, uint64_t bits, int chunks) "Added Block: '%s':%d, addr: %" PRIu64 ", offset: %" PRIu64 " length: %" PRIu64 " end: %" PRIu64 " bits %" PRIu64 " chunks %d"
> -rdma_delete_block(int block, uint64_t addr, uint64_t offset, uint64_t len, uint64_t end, uint64_t bits, int chunks) "Deleted Block: %d, addr: %" PRIu64 ", offset: %" PRIu64 " length: %" PRIu64 " end: %" PRIu64 " bits %" PRIu64 " chunks %d"
> +rdma_delete_block(void *block, uint64_t addr, uint64_t offset, uint64_t len, uint64_t end, uint64_t bits, int chunks) "Deleted Block: %p, addr: %" PRIu64 ", offset: %" PRIu64 " length: %" PRIu64 " end: %" PRIu64 " bits %" PRIu64 " chunks %d"
> rdma_start_incoming_migration(void) ""
> rdma_start_incoming_migration_after_dest_init(void) ""
> rdma_start_incoming_migration_after_rdma_listen(void) ""
These messages are also empty? What happened to them? =)
next prev parent reply other threads:[~2015-06-11 18:37 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 17:17 [Qemu-devel] [PATCH v2 00/12] Remove RDMA migration dependence on RAMBlock offset Dr. David Alan Gilbert (git)
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 01/12] Rename RDMA structures to make destination clear Dr. David Alan Gilbert (git)
2015-07-01 8:36 ` Juan Quintela
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 02/12] qemu_ram_foreach_block: pass up error value, and down the ramblock name Dr. David Alan Gilbert (git)
2015-07-01 8:36 ` Juan Quintela
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 03/12] Remove unneeded memset Dr. David Alan Gilbert (git)
2015-07-01 8:37 ` Juan Quintela
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 04/12] rdma typos Dr. David Alan Gilbert (git)
2015-06-11 17:56 ` Michael R. Hines
2015-06-11 18:37 ` Dr. David Alan Gilbert
2015-07-01 8:37 ` Juan Quintela
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 05/12] Store block name in local blocks structure Dr. David Alan Gilbert (git)
2015-07-01 8:38 ` Juan Quintela
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 06/12] Translate offsets to destination address space Dr. David Alan Gilbert (git)
2015-06-11 18:12 ` Michael R. Hines
2015-06-11 18:58 ` Dr. David Alan Gilbert
2015-06-11 19:08 ` Michael R. Hines
2015-06-12 18:50 ` Dr. David Alan Gilbert
2015-06-12 19:17 ` Michael R. Hines
2015-07-01 8:43 ` Juan Quintela
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 07/12] Rework ram_control_load_hook to hook during block load Dr. David Alan Gilbert (git)
2015-06-11 18:20 ` Michael R. Hines
2015-06-11 18:44 ` Dr. David Alan Gilbert
2015-07-01 8:47 ` Juan Quintela
2015-07-01 8:49 ` Juan Quintela
2015-07-01 8:51 ` Dr. David Alan Gilbert
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 08/12] Allow rdma_delete_block to work without the hash Dr. David Alan Gilbert (git)
2015-06-11 18:36 ` Michael R. Hines [this message]
2015-06-11 18:39 ` Dr. David Alan Gilbert
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 09/12] Rework ram block hash Dr. David Alan Gilbert (git)
2015-06-11 18:40 ` Michael R. Hines
2015-06-11 18:45 ` Dr. David Alan Gilbert
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 10/12] Sort destination RAMBlocks to be the same as the source Dr. David Alan Gilbert (git)
2015-06-11 18:55 ` Michael R. Hines
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 11/12] Sanity check RDMA remote data Dr. David Alan Gilbert (git)
2015-06-11 17:17 ` [Qemu-devel] [PATCH v2 12/12] Fail more cleanly in mismatched RAM cases Dr. David Alan Gilbert (git)
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=5579D533.9070608@linux.vnet.ibm.com \
--to=mrhines@linux.vnet.ibm.com \
--cc=amit.shah@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=dgilbert@redhat.com \
--cc=mrhines@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).