From patchwork Fri May 5 17:03:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pavel Tatashin X-Patchwork-Id: 759107 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wKJNW31Bfz9s7r for ; Sat, 6 May 2017 03:12:11 +1000 (AEST) Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 3wKJNW0p1tzDqNB for ; Sat, 6 May 2017 03:12:11 +1000 (AEST) X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3wKJBb2BYbzDqFJ for ; Sat, 6 May 2017 03:03:35 +1000 (AEST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v45H3Q2D027095 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 5 May 2017 17:03:26 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v45H3PZX011226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 5 May 2017 17:03:26 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v45H3ONR003047; Fri, 5 May 2017 17:03:24 GMT Received: from ca-ldom103.us.oracle.com (/10.129.68.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 May 2017 10:03:24 -0700 From: Pavel Tatashin To: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, borntraeger@de.ibm.com, heiko.carstens@de.ibm.com, davem@davemloft.net Subject: [v3 4/9] mm: do not zero vmemmap_buf Date: Fri, 5 May 2017 13:03:11 -0400 Message-Id: <1494003796-748672-5-git-send-email-pasha.tatashin@oracle.com> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1494003796-748672-1-git-send-email-pasha.tatashin@oracle.com> References: <1494003796-748672-1-git-send-email-pasha.tatashin@oracle.com> X-Source-IP: userv0021.oracle.com [156.151.31.71] X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" alloc_block_buf() can either use external allocator by calling vmemmap_alloc_block() or when available use pre-allocated vmemmap_buf to do allocation. In either case, alloc_block_buf() knows when to zero memory based on the "zero" argument. This is why it is not needed to zero vmemmap_buf beforehand. Let clients of alloc_block_buf() to decide whether that is needed. Signed-off-by: Pavel Tatashin --- mm/sparse-vmemmap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index 5d255b0..1e9508b 100644 --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -305,7 +305,7 @@ void __init sparse_mem_maps_populate_node(struct page **map_map, size = ALIGN(size, PMD_SIZE); vmemmap_buf_start = __earlyonly_bootmem_alloc(nodeid, size - * map_count, PMD_SIZE, __pa(MAX_DMA_ADDRESS), true); + * map_count, PMD_SIZE, __pa(MAX_DMA_ADDRESS), false); if (vmemmap_buf_start) { vmemmap_buf = vmemmap_buf_start;