From patchwork Fri Nov 22 01:53:49 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 11257135 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E5FA314C0 for ; Fri, 22 Nov 2019 01:53:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A97A22067D for ; Fri, 22 Nov 2019 01:53:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="JMS29L8K" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A97A22067D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E7C586B0494; Thu, 21 Nov 2019 20:53:51 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id E534D6B0495; Thu, 21 Nov 2019 20:53:51 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8FFF6B0496; Thu, 21 Nov 2019 20:53:51 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0238.hostedemail.com [216.40.44.238]) by kanga.kvack.org (Postfix) with ESMTP id C41786B0494 for ; Thu, 21 Nov 2019 20:53:51 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 83104180AD81A for ; Fri, 22 Nov 2019 01:53:51 +0000 (UTC) X-FDA: 76182242262.21.price85_5bdb6ce443f5c X-Spam-Summary: 2,0,0,b2c2db244036b8c9,d41d8cd98f00b204,akpm@linux-foundation.org,:akpm@linux-foundation.org:david@redhat.com::mhocko@suse.com:mm-commits@vger.kernel.org:osalvador@suse.de:pasha.tatashin@soleen.com:torvalds@linux-foundation.org:vincent.whitchurch@axis.com,RULES_HIT:41:355:379:800:960:967:973:988:989:1260:1263:1345:1381:1431:1437:1534:1542:1711:1730:1747:1777:1792:2198:2199:2393:2525:2559:2563:2682:2685:2859:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:5007:6261:6653:7576:7903:8599:8603:8660:9025:9545:10004:10913:11026:11473:11658:11914:12043:12048:12297:12438:12517:12519:12555:12679:12783:12986:13148:13230:13846:13869:14181:14721:14849:21063:21067:21080:21451:21627:21740:21795:21939:30005:30012:30051:30054,0,RBL:error,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules: 0:0:0,LF X-HE-Tag: price85_5bdb6ce443f5c X-Filterd-Recvd-Size: 3342 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Fri, 22 Nov 2019 01:53:51 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DDAF420692; Fri, 22 Nov 2019 01:53:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574387630; bh=GUtZ281BGBLSSwvJdttO1ArPz6dJmsly+Xp3hMbIG9M=; h=Date:From:To:Subject:From; b=JMS29L8K+ipPKwiSjUybUJua42qAHJfXl2BzRRxuBlC2r9bHE7Lr19QrWh5Kjw3EW SvqLx5umD7SCg8z0YGPI1R0lcCUvKQhd2u8dCRsi5XtxesuffBgKV9AozcjTS5Th1+ f51j5AGGBNIEb/ZSIywM3Axw0eFvo7qkSsayhx5o= Date: Thu, 21 Nov 2019 17:53:49 -0800 From: akpm@linux-foundation.org To: akpm@linux-foundation.org, david@redhat.com, linux-mm@kvack.org, mhocko@suse.com, mm-commits@vger.kernel.org, osalvador@suse.de, pasha.tatashin@soleen.com, torvalds@linux-foundation.org, vincent.whitchurch@axis.com Subject: [patch 1/4] mm/sparse: consistently do not zero memmap Message-ID: <20191122015349.DnuP3a202%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Vincent Whitchurch Subject: mm/sparse: consistently do not zero memmap sparsemem without VMEMMAP has two allocation paths to allocate the memory needed for its memmap (done in sparse_mem_map_populate()). In one allocation path (sparse_buffer_alloc() succeeds), the memory is not zeroed (since it was previously allocated with memblock_alloc_try_nid_raw()). In the other allocation path (sparse_buffer_alloc() fails and sparse_mem_map_populate() falls back to memblock_alloc_try_nid()), the memory is zeroed. AFAICS this difference does not appear to be on purpose. If the code is supposed to work with non-initialized memory (__init_single_page() takes care of zeroing the struct pages which are actually used), we should consistently not zero the memory, to avoid masking bugs. (I noticed this because on my ARM64 platform, with 1 GiB of memory the first [and only] section is allocated from the zeroing path while with 2 GiB of memory the first 1 GiB section is allocated from the non-zeroing path.) Michal: "the main user visible problem is a memory wastage. The overal amount of memory should be small. I wouldn't call it stable material." Link: http://lkml.kernel.org/r/20191030131122.8256-1-vincent.whitchurch@axis.com Signed-off-by: Vincent Whitchurch Acked-by: Michal Hocko Acked-by: David Hildenbrand Reviewed-by: Oscar Salvador Reviewed-by: Pavel Tatashin Signed-off-by: Andrew Morton --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/sparse.c~mm-sparse-consistently-do-not-zero-memmap +++ a/mm/sparse.c @@ -458,7 +458,7 @@ struct page __init *__populate_section_m if (map) return map; - map = memblock_alloc_try_nid(size, + map = memblock_alloc_try_nid_raw(size, PAGE_SIZE, addr, MEMBLOCK_ALLOC_ACCESSIBLE, nid); if (!map)