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=-3.8 required=3.0 tests=BAYES_00, 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 44725C4361B for ; Mon, 7 Dec 2020 18:38:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B549A20449 for ; Mon, 7 Dec 2020 18:38:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B549A20449 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 3392B8D0009; Mon, 7 Dec 2020 13:38:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C1078D0001; Mon, 7 Dec 2020 13:38:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B2228D0009; Mon, 7 Dec 2020 13:38:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0195.hostedemail.com [216.40.44.195]) by kanga.kvack.org (Postfix) with ESMTP id 051478D0001 for ; Mon, 7 Dec 2020 13:38:22 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B9D18181AC544 for ; Mon, 7 Dec 2020 18:38:21 +0000 (UTC) X-FDA: 77567346402.16.dress53_1c047d2273e0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 95929100E6903 for ; Mon, 7 Dec 2020 18:38:21 +0000 (UTC) X-HE-Tag: dress53_1c047d2273e0 X-Filterd-Recvd-Size: 3639 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Dec 2020 18:38:20 +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 89856AD63; Mon, 7 Dec 2020 18:38:19 +0000 (UTC) Date: Mon, 7 Dec 2020 19:38:14 +0100 From: Oscar Salvador To: Muchun Song Cc: Mike Kravetz , Andrew Morton , Jonathan Corbet , dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, bp@alien8.de, mingo@redhat.com, Thomas Gleixner , pawan.kumar.gupta@linux.intel.com, mchehab+huawei@kernel.org, paulmck@kernel.org, viro@zeniv.linux.org.uk, Peter Zijlstra , luto@kernel.org, oneukum@suse.com, jroedel@suse.de, Matthew Wilcox , David Rientjes , Mina Almasry , Randy Dunlap , anshuman.khandual@arm.com, Michal Hocko , "Song Bao Hua (Barry Song)" , Xiongchun duan , LKML , Linux Memory Management List , linux-doc@vger.kernel.org, linux-fsdevel Subject: Re: [External] Re: [PATCH v7 00/15] Free some vmemmap pages of hugetlb page Message-ID: <20201207183814.GA3786@localhost.localdomain> References: <20201130151838.11208-1-songmuchun@bytedance.com> <600fd7e2-70b4-810f-8d12-62cba80af80d@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Fri, Dec 04, 2020 at 11:39:31AM +0800, Muchun Song wrote: > On Fri, Dec 4, 2020 at 7:49 AM Mike Kravetz wrote: > > As previously mentioned, I feel qualified to review the hugetlb changes > > and some other closely related changes. However, this patch set is > > touching quite a few areas and I do not feel qualified to make authoritative > > statements about them all. I too hope others will take a look. > > Agree. I also hope others can take a look at other modules(e.g. > sparse-vmemmap, memory-hotplug). Thanks for everyone's efforts > on this. I got sidetracked by some other stuff but I plan to continue reviewing this series. One thing that came to my mind is that if we do as David suggested in patch#4, and we move it towards the end to actually __enable__ this once all the infrastructure is there (unless hstate->nr_vmemmap_pages differs from 0 we should not be doing any work AFAIK), we could also move patch#6 to the end (right before the enablement), kill patch#7 and only leave patch#13. The reason for that (killing patch#7 and leaving patch#13 only) is that it does not make much sense to me to disable PMD-mapped vmemmap depending on the CONFIG_HUGETLB_xxxxx as that is enabled by default to replace that later by the boot kernel parameter. It looks more natural to me to disable it when we introduce the kernel boot parameter, before the actual enablement of the feature. As I said, I plan to start the review again, but the order above would make more sense to me. thanks -- Oscar Salvador SUSE L3