From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58274)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1WzsPF-0002Wq-Cs
	for qemu-devel@nongnu.org; Wed, 25 Jun 2014 14:59:02 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1WzsP6-0005FZ-B0
	for qemu-devel@nongnu.org; Wed, 25 Jun 2014 14:58:53 -0400
Received: from mail-we0-x229.google.com ([2a00:1450:400c:c03::229]:36960)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1WzsP6-0005FP-4r
	for qemu-devel@nongnu.org; Wed, 25 Jun 2014 14:58:44 -0400
Received: by mail-we0-f169.google.com with SMTP id t60so2535213wes.14
	for <qemu-devel@nongnu.org>; Wed, 25 Jun 2014 11:58:43 -0700 (PDT)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <53AB1BDD.7080007@redhat.com>
Date: Wed, 25 Jun 2014 20:58:37 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <53AB0C7C.1050805@gmail.com>
In-Reply-To: <53AB0C7C.1050805@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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: Etienne Martineau <etmartinau@gmail.com>, gonglei <arei.gonglei@huawei.com>, Fam <famz@redhat.com>, Peter Crosthwaite <peter.crosthwaite@xilinx.com>, qemu-devel@nongnu.org

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.

Paolo