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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 C10AACA9EC5 for ; Wed, 30 Oct 2019 15:20:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 798D420679 for ; Wed, 30 Oct 2019 15:20:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=soleen.com header.i=@soleen.com header.b="aUtgADL5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 798D420679 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=soleen.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 194EB6B027C; Wed, 30 Oct 2019 11:20:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16CC26B027D; Wed, 30 Oct 2019 11:20:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0820A6B027E; Wed, 30 Oct 2019 11:20:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id DCD7E6B027C for ; Wed, 30 Oct 2019 11:20:57 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 86625180ACF86 for ; Wed, 30 Oct 2019 15:20:57 +0000 (UTC) X-FDA: 76100813754.25.toes97_7cb86b1b8d730 X-HE-Tag: toes97_7cb86b1b8d730 X-Filterd-Recvd-Size: 5176 Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Oct 2019 15:20:56 +0000 (UTC) Received: by mail-ed1-f65.google.com with SMTP id k2so2074246edx.2 for ; Wed, 30 Oct 2019 08:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3WelAeH2c+ewUFXMqzibHzNrbO0iv8d5R7fbVULwLqc=; b=aUtgADL5DK0nImfhe/gfmEFtgWdBGRsYsp06B7dPmIh6ijzq/OsArBiemDsg8NxCO2 DY6MdSqBP+xrfoWYwvyzkYHeILfLsJFHI+xpo41raCQITr+AhKMITt7bzSz+uHKU0dNE 7Psn8QOTNIvxhPhsQ92pJZOSzcQAYuXG3mRLJecqPX+e4lWKMN0vaJ52eg26VQpYxW4+ 9YIUTtJUxAv7Q/lbJZynFXrOqG5IRw4qjlBatFFyXEei2CbqaMrLJYHsscQLHqAhOKeh bmInSTZG6AAgtkiinMYvPV10YusjDcEfu00m7/PzjBF5W4JCjGQVmcE8K0Qok6T7nenB kJ7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3WelAeH2c+ewUFXMqzibHzNrbO0iv8d5R7fbVULwLqc=; b=pMexkbYgi2b2wYHEVTcDtJkJKAkNU0neyTi9+T5BCEYpZPZdW1zVJ28YxbMAkEIC8v eeL3Vocc7ueO2lU1XgQtda6onSHiAjMVcKjMnRO66WgTCWZYUPvG4wnXCSumqJlPGNVn g5hg5A4J81B47zHeCYhPLh8hPoDPA3WzKiezlLljZrnigZwR7/nv1xXIaFQlo9NlMW5A lN+jKZMtnQ+fXdBQNBFBKyIbBqMP8MPRlpxyCkreAvNfhXPQAb06r3q6nrgy3WR2cKn8 WifWnRKghQBi43iKcTEylkpdXkNF4wU17RWG+FnkxsCdDObunURZLqs6tkXNViSiWJhB sk+Q== X-Gm-Message-State: APjAAAVmvY4HAcaGBxX0CUb4ZMVHE6A371UbpkEeA4ILIvD3sS0Ejk40 tdbu02+DspoMkTkv3KQvmfteJU4DDGEKhj4htqY5oA== X-Google-Smtp-Source: APXvYqwFwie01ABPFi/VnwYag197buGFTQ/FM/qpCjhAqJ0fW94Xei/rjs0hwu+Rrk6alIe27zn9uJYl3/OHuXZQoxc= X-Received: by 2002:a17:906:6993:: with SMTP id i19mr9566232ejr.259.1572448855629; Wed, 30 Oct 2019 08:20:55 -0700 (PDT) MIME-Version: 1.0 References: <20191030131122.8256-1-vincent.whitchurch@axis.com> <20191030132958.GD31513@dhcp22.suse.cz> <20191030140216.i26n22asgafckfxy@axis.com> <20191030141259.GE31513@dhcp22.suse.cz> In-Reply-To: <20191030141259.GE31513@dhcp22.suse.cz> From: Pavel Tatashin Date: Wed, 30 Oct 2019 11:20:44 -0400 Message-ID: Subject: Re: [PATCH] mm/sparse: Consistently do not zero memmap To: Michal Hocko Cc: Vincent Whitchurch , "akpm@linux-foundation.org" , "osalvador@suse.de" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" 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: On Wed, Oct 30, 2019 at 10:13 AM Michal Hocko wrote: > > [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? I remember thinking about this large alignment, as it looked out of place to me also. It was there to keep memmap in single chunks on larger x86 machines. Perhaps it can be revisited now. The patch that introduced this alignment: 9bdac914240759457175ac0d6529a37d2820bc4d vmemmap_alloc_block_buf + ptr = (void *)ALIGN((unsigned long)vmemmap_buf, size); Pasha