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 D531EC0018C for ; Mon, 7 Dec 2020 18:39:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 96396238E7 for ; Mon, 7 Dec 2020 18:39:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726031AbgLGSjB (ORCPT ); Mon, 7 Dec 2020 13:39:01 -0500 Received: from mx2.suse.de ([195.135.220.15]:40950 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725822AbgLGSjB (ORCPT ); Mon, 7 Dec 2020 13:39:01 -0500 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: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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