From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:54310)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <etmartinau@gmail.com>) id 1Wzu0f-0002Xd-5C
	for qemu-devel@nongnu.org; Wed, 25 Jun 2014 16:41:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <etmartinau@gmail.com>) id 1Wzu0V-0006wj-Um
	for qemu-devel@nongnu.org; Wed, 25 Jun 2014 16:41:37 -0400
Received: from mail-ie0-x232.google.com ([2607:f8b0:4001:c03::232]:61552)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <etmartinau@gmail.com>) id 1Wzu0V-0006wW-PO
	for qemu-devel@nongnu.org; Wed, 25 Jun 2014 16:41:27 -0400
Received: by mail-ie0-f178.google.com with SMTP id rd18so2209307iec.9
	for <qemu-devel@nongnu.org>; Wed, 25 Jun 2014 13:41:26 -0700 (PDT)
Message-ID: <53AB33EF.5060602@gmail.com>
Date: Wed, 25 Jun 2014 16:41:19 -0400
From: Etienne Martineau <etmartinau@gmail.com>
MIME-Version: 1.0
References: <53AB0C7C.1050805@gmail.com> <53AB1BDD.7080007@redhat.com>
In-Reply-To: <53AB1BDD.7080007@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] memory: memory_region_transaction_commit() slow
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: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>, gonglei <arei.gonglei@huawei.com>, Fam <famz@redhat.com>, qemu-devel@nongnu.org

On 14-06-25 02:58 PM, Paolo Bonzini wrote:
> Il 25/06/2014 19:53, Etienne Martineau ha scritto:
>>
>> It seems to me that there is a scale issue O(n) in memory_region_transaction_commit().
>>
>> Basically the time it takes to rebuild the memory view during device assignment
>> pci_bridge_update_mappings() increase linearly with respect to the number of
>> device already assigned to the guest.
> 
> That's correct, unfortunately.  It can be fixed, it's not hard but also not trivial.
> 
> Basically you can detect address spaces whose memory region is an alias of an address space's root memory region.  You can then reuse that address space's FlatView instead of building another one.

Thanks for your reply.

I'm not too sure to understand what you mean by 'reuse that address space's flatview'?

Are you suggesting to push update directly in the flatview? If so then any further 
update to that address space will wipe out the flatview changes previously done isn't.

thanks,
Etienne