From patchwork Mon Jul 11 09:31:47 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Lieven X-Patchwork-Id: 9223095 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id ED721604DB for ; Mon, 11 Jul 2016 09:32:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DBA7A24B5E for ; Mon, 11 Jul 2016 09:32:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CE86F2793D; Mon, 11 Jul 2016 09:32:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 1F9E024B5E for ; Mon, 11 Jul 2016 09:32:20 +0000 (UTC) Received: from localhost ([::1]:59180 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMXZb-0000it-Kk for patchwork-qemu-devel@patchwork.kernel.org; Mon, 11 Jul 2016 05:32:19 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMXZL-0000Ye-RT for qemu-devel@nongnu.org; Mon, 11 Jul 2016 05:32:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMXZF-0006zn-Pc for qemu-devel@nongnu.org; Mon, 11 Jul 2016 05:32:02 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:43164 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMXZF-0006ze-Fk for qemu-devel@nongnu.org; Mon, 11 Jul 2016 05:31:57 -0400 Received: (qmail 1198 invoked by uid 89); 11 Jul 2016 09:31:55 -0000 Received: from [195.62.97.28] by client-16-kamp (envelope-from , uid 89) with qmail-scanner-2010/03/19-MF (clamdscan: 0.99.2/21882. hbedv: 8.3.40.44/7.12.99.34. avast: 1.2.2/16071100. spamassassin: 3.4.1. Clear:RC:1(195.62.97.28):. Processed in 0.094564 secs); 11 Jul 2016 09:31:55 -0000 Received: from smtp.kamp.de (HELO submission.kamp.de) ([195.62.97.28]) by mx01.kamp.de with ESMTPS (DHE-RSA-AES256-GCM-SHA384 encrypted); 11 Jul 2016 09:31:54 -0000 X-GL_Whitelist: yes Received: (qmail 28791 invoked from network); 11 Jul 2016 09:31:53 -0000 Received: from lieven-pc.kamp-intra.net (HELO ?172.21.12.60?) (pl@kamp.de@::ffff:172.21.12.60) by submission.kamp.de with ESMTPS (DHE-RSA-AES128-SHA encrypted) ESMTPA; 11 Jul 2016 09:31:53 -0000 To: Paolo Bonzini , qemu-devel@nongnu.org References: <1467104499-27517-1-git-send-email-pl@kamp.de> <1467104499-27517-14-git-send-email-pl@kamp.de> From: Peter Lieven Message-ID: <57836783.4070100@kamp.de> Date: Mon, 11 Jul 2016 11:31:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a02:248:0:51::16 Subject: Re: [Qemu-devel] [PATCH 13/15] exec: use mmap for PhysPageMap->nodes X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, peter.maydell@linaro.org, mst@redhat.com, dgilbert@redhat.com, mreitz@redhat.com, kraxel@redhat.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP Am 28.06.2016 um 12:43 schrieb Paolo Bonzini: > > On 28/06/2016 11:01, Peter Lieven wrote: >> this was causing serious framentation in conjunction with the >> subpages since RCU was introduced. The node space was allocated >> at approx 32kB then reallocted to approx 75kB and this a few hundred >> times at startup. And thanks to RCU the freeing was delayed. >> >> Signed-off-by: Peter Lieven > The size of the node from the previous as->dispatch could be used as a > hint for the new one perhaps, avoiding the reallocation? This here seems also to work: Question is still, mmap for this? Peter diff --git a/exec.c b/exec.c index 0122ef7..2691c0a 100644 --- a/exec.c +++ b/exec.c @@ -187,10 +187,12 @@ struct CPUAddressSpace { static void phys_map_node_reserve(PhysPageMap *map, unsigned nodes) { + static unsigned alloc_hint = 16; if (map->nodes_nb + nodes > map->nodes_nb_alloc) { - map->nodes_nb_alloc = MAX(map->nodes_nb_alloc * 2, 16); + map->nodes_nb_alloc = MAX(map->nodes_nb_alloc, alloc_hint); map->nodes_nb_alloc = MAX(map->nodes_nb_alloc, map->nodes_nb + nodes); map->nodes = g_renew(Node, map->nodes, map->nodes_nb_alloc); + alloc_hint = map->nodes_nb_alloc; } }