From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vkpq1-0000Td-EM for qemu-devel@nongnu.org; Mon, 25 Nov 2013 01:40:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vkpps-0001LH-Dc for qemu-devel@nongnu.org; Mon, 25 Nov 2013 01:40:05 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]:40251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vkpps-0001LD-6t for qemu-devel@nongnu.org; Mon, 25 Nov 2013 01:39:56 -0500 Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 24 Nov 2013 23:39:55 -0700 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id C9BEB3E40026 for ; Sun, 24 Nov 2013 23:39:53 -0700 (MST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by b03cxnp08025.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAP4c5Mn6423018 for ; Mon, 25 Nov 2013 05:38:05 +0100 Received: from d03av03.boulder.ibm.com (localhost [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAP6dr0W025290 for ; Sun, 24 Nov 2013 23:39:53 -0700 Message-ID: <5292F0B7.6040909@linux.vnet.ibm.com> Date: Mon, 25 Nov 2013 14:39:51 +0800 From: "Michael R. Hines" MIME-Version: 1.0 References: <1383743088-8139-1-git-send-email-quintela@redhat.com> <1383748635.1739.92.camel@nilsson.home.kraxel.org> <527A6510.9080504@redhat.com> In-Reply-To: <527A6510.9080504@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 00/39] bitmap handling optimization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, chegu_vinod@hp.com, Gerd Hoffmann , Juan Quintela On 11/06/2013 11:49 PM, Paolo Bonzini wrote: > Il 06/11/2013 15:37, Gerd Hoffmann ha scritto: >>>> - vga ram by default is not aligned in a page number multiple of >>>> 64, >>>> >>>> it could be optimized. Kraxel? It syncs the kvm bitmap at least >>>> 1 a second or so? bitmap is only 2048 pages (16MB by default). We >>>> need to change the ram_addr only >> It is created using memory_region_init_ram(), in vga_common_init(). >> Nothing special is done to avoid/force any alignment. Dunno why it >> ends up on a odd page number. > Because some random option ROM is loaded before the RAM region is > created, and thus the ram_addr_t's become misaligned. Keeping the > ram_addr_t's aligned in find_ram_offset is easy: > > diff --git a/exec.c b/exec.c > index 79610ce..1b82e81 100644 > --- a/exec.c > +++ b/exec.c > @@ -1002,7 +1002,7 @@ static ram_addr_t find_ram_offset(ram_addr_t size) > QTAILQ_FOREACH(block, &ram_list.blocks, next) { > ram_addr_t end, next = RAM_ADDR_MAX; > > - end = block->offset + block->length; > + end = ROUND_UP(block->offset + block->length, TARGET_PAGE_SIZE * 64); > > QTAILQ_FOREACH(next_block, &ram_list.blocks, next) { > if (next_block->offset >= end) { > > but I'm not sure if we're allowed to change the ram_addr_t's. On one hand they > are not part of guest ABI, on the other hand RDMA migration uses them > in the protocol. > > Michael, can you check if RDMA migration works from a QEMU *without* > this patch to one *with*: > > diff --git a/exec.c b/exec.c > index 79610ce..21b8b96 100644 > --- a/exec.c > +++ b/exec.c > @@ -997,7 +997,7 @@ static ram_addr_t find_ram_offset(ram_addr_t size) > assert(size != 0); /* it would hand out same offset multiple times */ > > if (QTAILQ_EMPTY(&ram_list.blocks)) > - return 0; > + return TARGET_PAGE_SIZE * 100; > > QTAILQ_FOREACH(block, &ram_list.blocks, next) { > ram_addr_t end, next = RAM_ADDR_MAX; > > I suspect it doesn't. But perhaps we still have time before RDMA > becomes non-experimental. > > Paolo > I tested the patch as requested. It doesn't seem to break the migration. I compiled and looped the migration a couple of times and it runs through. Sorry for the late reply. - Michael