From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1duw0D-0002PS-2z for qemu-devel@nongnu.org; Thu, 21 Sep 2017 03:34:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1duw09-0000Hx-Ts for qemu-devel@nongnu.org; Thu, 21 Sep 2017 03:34:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60822) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1duw09-0000H3-OI for qemu-devel@nongnu.org; Thu, 21 Sep 2017 03:34:25 -0400 Date: Thu, 21 Sep 2017 03:34:24 -0400 (EDT) From: Paolo Bonzini Message-ID: <222247850.7271421.1505979264047.JavaMail.zimbra@redhat.com> In-Reply-To: References: <20170920114637.42004-1-aik@ozlabs.ru> <20170920114637.42004-19-aik@ozlabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu v4 18/18] memory: Give memory_region_transaction_commit a hint List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: qemu-devel@nongnu.org ----- Original Message ----- > From: "Alexey Kardashevskiy" > To: "Paolo Bonzini" , qemu-devel@nongnu.org > Sent: Thursday, September 21, 2017 2:02:02 AM > Subject: Re: [PATCH qemu v4 18/18] memory: Give memory_region_transaction_commit a hint > > On 21/09/17 03:14, Paolo Bonzini wrote: > > On 20/09/2017 13:46, Alexey Kardashevskiy wrote: > >> This extends memory_region_transaction_commit() to receive a MR as > >> if it is a root MR or its topmost parent is, then we can only rebuild > >> its FlatView and update it for address spaces sharing it. > >> > >> The optimization gets disabled though if there is full update about to > >> commit. > >> > >> memory_region_set_enabled() is a special case here, it does not use > >> a hint when MR is being disabled. > >> > >> On POWER8 with 255 CPUs, 255 virtio-net, 40 PCI bridges guest this brings > >> down the boot time from 20s to 12s, the total memory footprint > >> goes down (17G -> 8G). > > > > I think this is incorrect if MR has an alias (no matter if enabling or > > disabling)? > > Hmmm. Right. I can add a aliases_nr counter to an MR (it does not even have > to go down as aliases are not creared/destroyed often) and take the slow > path if it is not zero, does it make sense? It should be a separate series anyway. Let's get the infrastructure in so it's easier to experiment. Paolo