From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ve5Me-0007zW-Tb for qemu-devel@nongnu.org; Wed, 06 Nov 2013 10:50:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ve5MU-00062X-VS for qemu-devel@nongnu.org; Wed, 06 Nov 2013 10:49:52 -0500 Received: from mail-qc0-x22b.google.com ([2607:f8b0:400d:c01::22b]:57347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ve5MU-00060n-Qd for qemu-devel@nongnu.org; Wed, 06 Nov 2013 10:49:42 -0500 Received: by mail-qc0-f171.google.com with SMTP id i7so6097656qcq.30 for ; Wed, 06 Nov 2013 07:49:41 -0800 (PST) Sender: Paolo Bonzini Message-ID: <527A6510.9080504@redhat.com> Date: Wed, 06 Nov 2013 16:49:36 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1383743088-8139-1-git-send-email-quintela@redhat.com> <1383748635.1739.92.camel@nilsson.home.kraxel.org> In-Reply-To: <1383748635.1739.92.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=UTF-8 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: Gerd Hoffmann Cc: chegu_vinod@hp.com, qemu-devel@nongnu.org, "Michael R. Hines" , Juan Quintela 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