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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 04F59C433E0 for ; Fri, 19 Mar 2021 09:00:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 61BBE64F40 for ; Fri, 19 Mar 2021 09:00:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 61BBE64F40 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D96346B006E; Fri, 19 Mar 2021 05:00:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D48CC6B0071; Fri, 19 Mar 2021 05:00:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD87D6B0072; Fri, 19 Mar 2021 05:00:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0067.hostedemail.com [216.40.44.67]) by kanga.kvack.org (Postfix) with ESMTP id A57EF6B0071 for ; Fri, 19 Mar 2021 05:00:00 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 65DEF1802E6C0 for ; Fri, 19 Mar 2021 09:00:00 +0000 (UTC) X-FDA: 77936026518.28.352BCFC Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf08.hostedemail.com (Postfix) with ESMTP id B1B8880192DA for ; Fri, 19 Mar 2021 08:59:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 63818AC1F; Fri, 19 Mar 2021 08:59:58 +0000 (UTC) Date: Fri, 19 Mar 2021 09:59:53 +0100 From: Oscar Salvador To: Muchun Song Cc: corbet@lwn.net, mike.kravetz@oracle.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, rdunlap@infradead.org, oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, almasrymina@google.com, rientjes@google.com, willy@infradead.org, mhocko@suse.com, song.bao.hua@hisilicon.com, david@redhat.com, naoya.horiguchi@nec.com, joao.m.martins@oracle.com, duanxiongchun@bytedance.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Miaohe Lin , Chen Huang , Bodeddula Balasubramaniam Subject: Re: [PATCH v19 7/8] mm: hugetlb: add a kernel parameter hugetlb_free_vmemmap Message-ID: <20210319085948.GA5695@linux> References: <20210315092015.35396-1-songmuchun@bytedance.com> <20210315092015.35396-8-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210315092015.35396-8-songmuchun@bytedance.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Stat-Signature: ske4wefrx9hkhgckaixzb57jkwt4uzf1 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B1B8880192DA Received-SPF: none (suse.de>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1616144396-32324 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 Mon, Mar 15, 2021 at 05:20:14PM +0800, Muchun Song wrote: > --- a/arch/x86/mm/init_64.c > +++ b/arch/x86/mm/init_64.c > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -1557,7 +1558,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > { > int err; > > - if (end - start < PAGES_PER_SECTION * sizeof(struct page)) > + if ((is_hugetlb_free_vmemmap_enabled() && !altmap) || > + end - start < PAGES_PER_SECTION * sizeof(struct page)) > err = vmemmap_populate_basepages(start, end, node, NULL); > else if (boot_cpu_has(X86_FEATURE_PSE)) > err = vmemmap_populate_hugepages(start, end, node, altmap); I've been thinking about this some more. Assume you opt-in the hugetlb-vmemmap feature, and assume you pass a valid altmap to vmemmap_populate. This will lead to use populating the vmemmap array with hugepages. What if then, a HugeTLB gets allocated and falls within that memory range (backed by hugetpages)? AFAIK, this will get us in trouble as currently the code can only operate on memory backed by PAGE_SIZE pages, right? I cannot remember, but I do not think nothing prevents that from happening? Am I missing anything? -- Oscar Salvador SUSE L3