From patchwork Fri Jul 15 10:03:50 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Lieven X-Patchwork-Id: 9231501 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 5F3CB60865 for ; Fri, 15 Jul 2016 10:04:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4FD8927CCB for ; Fri, 15 Jul 2016 10:04:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4453428319; Fri, 15 Jul 2016 10:04:59 +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 CC24527CCB for ; Fri, 15 Jul 2016 10:04:58 +0000 (UTC) Received: from localhost ([::1]:59592 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNzzO-0008AJ-22 for patchwork-qemu-devel@patchwork.kernel.org; Fri, 15 Jul 2016 06:04:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNzyY-0007qX-5G for qemu-devel@nongnu.org; Fri, 15 Jul 2016 06:04:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNzyV-0008Rv-0Y for qemu-devel@nongnu.org; Fri, 15 Jul 2016 06:04:06 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:59600 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNzyU-0008RU-O5 for qemu-devel@nongnu.org; Fri, 15 Jul 2016 06:04:02 -0400 Received: (qmail 15845 invoked by uid 89); 15 Jul 2016 10:03:58 -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/21906. hbedv: 8.3.40.44/7.12.99.34. avast: 1.2.2/16071500. spamassassin: 3.4.1. Clear:RC:1(195.62.97.28):. Processed in 0.129267 secs); 15 Jul 2016 10:03:58 -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); 15 Jul 2016 10:03:57 -0000 X-GL_Whitelist: yes Received: (qmail 15971 invoked from network); 15 Jul 2016 10:03:56 -0000 Received: from lieven-pc.kamp-intra.net (HELO lieven-pc) (relay@kamp.de@::ffff:172.21.12.60) by submission.kamp.de with ESMTPS (DHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPA; 15 Jul 2016 10:03:56 -0000 Received: by lieven-pc (Postfix, from userid 1000) id D818C207EF; Fri, 15 Jul 2016 12:03:51 +0200 (CEST) From: Peter Lieven To: qemu-devel@nongnu.org Date: Fri, 15 Jul 2016 12:03:50 +0200 Message-Id: <1468577030-21097-1-git-send-email-pl@kamp.de> X-Mailer: git-send-email 1.9.1 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: [Qemu-devel] [PATCH] exec: avoid realloc in phys_map_node_reserve 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, armbru@redhat.com, Peter Lieven , dgilbert@redhat.com, mreitz@redhat.com, pbonzini@redhat.com, rth@twiddle.net Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP this is the first step in reducing the brk heap fragmentation created by the map->nodes memory allocation. Since the introduction of RCU the freeing of the PhysPageMaps is delayed so that sometimes several hundred are allocated at the same time. Even worse the memory for map->nodes is allocated and shortly afterwards reallocated. Since the number of nodes it grows to in the end is the same for all PhysPageMaps remember this value and at least avoid the reallocation. The large number of simultaneous allocations (about 450 x 70kB in my configuration) has to be addressed later. Signed-off-by: Peter Lieven --- exec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/exec.c b/exec.c index 011babd..60cf46a 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; } }