From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40625)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <quintela@redhat.com>) id 1W8SYv-0008LR-65
	for qemu-devel@nongnu.org; Wed, 29 Jan 2014 05:40:10 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <quintela@redhat.com>) id 1W8SYq-0004p4-0F
	for qemu-devel@nongnu.org; Wed, 29 Jan 2014 05:40:05 -0500
Received: from mx1.redhat.com ([209.132.183.28]:46992)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <quintela@redhat.com>) id 1W8SYp-0004oz-P0
	for qemu-devel@nongnu.org; Wed, 29 Jan 2014 05:39:59 -0500
From: Juan Quintela <quintela@redhat.com>
In-Reply-To: <52E8B80B.5060904@ozlabs.ru> (Alexey Kardashevskiy's message of
	"Wed, 29 Jan 2014 19:12:59 +1100")
References: <1390974639-24880-1-git-send-email-aik@ozlabs.ru>
	<52E8AE32.7000200@redhat.com> <52E8B80B.5060904@ozlabs.ru>
Date: Wed, 29 Jan 2014 11:39:55 +0100
Message-ID: <87txcn9imc.fsf@elfo.mitica>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel] [PATCH] Revert "memory: syncronize kvm bitmap
	using bitmaps operations"
Reply-To: quintela@redhat.com
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, Orit Wasserman <owasserm@redhat.com>

Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 01/29/2014 06:30 PM, Paolo Bonzini wrote:
>> Il 29/01/2014 06:50, Alexey Kardashevskiy ha scritto:
>>> Since 64K system page size is quite popular configuration on PPC64,
>>> the original patch breaks migration.
>>>
>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>> ---
>>>  include/exec/ram_addr.h | 54
>>> +++++++++++++++++--------------------------------
>>>  1 file changed, 18 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
>>> index 33c8acc..c6736ed 100644
>>> --- a/include/exec/ram_addr.h
>>> +++ b/include/exec/ram_addr.h
>>> @@ -83,47 +83,29 @@ static inline void
>>> cpu_physical_memory_set_dirty_lebitmap(unsigned long *bitmap,
>>>                                                            ram_addr_t start,
>>>                                                            ram_addr_t pages)
>>>  {
>>> -    unsigned long i, j;
>>> +    unsigned int i, j;
>>>      unsigned long page_number, c;
>>>      hwaddr addr;
>>>      ram_addr_t ram_addr;
>>> -    unsigned long len = (pages + HOST_LONG_BITS - 1) / HOST_LONG_BITS;
>>> +    unsigned int len = (pages + HOST_LONG_BITS - 1) / HOST_LONG_BITS;
>>>      unsigned long hpratio = getpagesize() / TARGET_PAGE_SIZE;
>>> -    unsigned long page = BIT_WORD(start >> TARGET_PAGE_BITS);
>>>
>>> -    /* start address is aligned at the start of a word? */
>>> -    if (((page * BITS_PER_LONG) << TARGET_PAGE_BITS) == start) {
>> 
>> Why not just add " && hpratio == 1" here?
>
>
> Or fix dirty map to make it 1 bit per system page size (may be the fix is
> coming, who knows, but I am just not ready to do this now). Or do tricks
> with bits and support hpratio!=1. I could not choose and decided to revert
> it for now :)

Please, could you test Paolo suggestion?

> Do we really earn a lot here?

With 512GB guests, we used to have stalls of 10 seconds, now they are
lost on the noise.

Thanks for the testing.

Later, Juan.