From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF3FACA9EC7 for ; Wed, 30 Oct 2019 14:13:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A6BEA20874 for ; Wed, 30 Oct 2019 14:13:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6BEA20874 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 45F036B0006; Wed, 30 Oct 2019 10:13:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4368F6B000A; Wed, 30 Oct 2019 10:13:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34C8D6B000C; Wed, 30 Oct 2019 10:13:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id 16DF86B0006 for ; Wed, 30 Oct 2019 10:13:03 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id A4B6D824999B for ; Wed, 30 Oct 2019 14:13:02 +0000 (UTC) X-FDA: 76100642604.01.sail81_71d4bfbd0ad04 X-HE-Tag: sail81_71d4bfbd0ad04 X-Filterd-Recvd-Size: 3030 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Oct 2019 14:13:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A7DC0B6B5; Wed, 30 Oct 2019 14:13:00 +0000 (UTC) Date: Wed, 30 Oct 2019 15:12:59 +0100 From: Michal Hocko To: Vincent Whitchurch , Pavel Tatashin Cc: "akpm@linux-foundation.org" , "osalvador@suse.de" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] mm/sparse: Consistently do not zero memmap Message-ID: <20191030141259.GE31513@dhcp22.suse.cz> References: <20191030131122.8256-1-vincent.whitchurch@axis.com> <20191030132958.GD31513@dhcp22.suse.cz> <20191030140216.i26n22asgafckfxy@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191030140216.i26n22asgafckfxy@axis.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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: [Add Pavel - the email thread starts http://lkml.kernel.org/r/20191030131122.8256-1-vincent.whitchurch@axis.com but it used your old email address] On Wed 30-10-19 15:02:16, Vincent Whitchurch wrote: > On Wed, Oct 30, 2019 at 02:29:58PM +0100, Michal Hocko wrote: > > On Wed 30-10-19 14:11:22, Vincent Whitchurch wrote: > > > (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.) > > > > Do I get it right that sparse_buffer_init couldn't allocate memmap for > > the full node for some reason and so sparse_init_nid would have to > > allocate one for each memory section? > > Not quite. The sparsemap_buf is successfully allocated with the correct > size in sparse_buffer_init(), but sparse_buffer_alloc() fails to > allocate the same size from it. > > The reason it fails is that sparse_buffer_alloc() for some reason wants > to return a pointer which is aligned to the allocation size. But the > sparsemap_buf was only allocated with PAGE_SIZE alignment so there's not > enough space to align it. > > I don't understand the reason for this alignment requirement since the > fallback path also allocates with PAGE_SIZE alignment. I'm guessing the > alignment is for the VMEMAP code which also uses sparse_buffer_alloc()? I am not 100% sure TBH. Aligning makes some sense when mapping the memmaps to page tables but that would suggest that sparse_buffer_init is using a wrong alignment then. It is quite wasteful to allocate alarge misaligned block like that. Your patch still makes sense but this is something to look into. Pavel? -- Michal Hocko SUSE Labs