linux-kernel - Re: [External] Re: [PATCH v7 00/15] Free some vmemmap pages of hugetlb page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201207183814.GA3786@localhost.localdomain>
Date:   Mon, 7 Dec 2020 19:38:14 +0100
From:   Oscar Salvador <osalvador@...e.de>
To:     Muchun Song <songmuchun@...edance.com>
Cc:     Mike Kravetz <mike.kravetz@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>, dave.hansen@...ux.intel.com,
        hpa@...or.com, x86@...nel.org, bp@...en8.de, mingo@...hat.com,
        Thomas Gleixner <tglx@...utronix.de>,
        pawan.kumar.gupta@...ux.intel.com, mchehab+huawei@...nel.org,
        paulmck@...nel.org, viro@...iv.linux.org.uk,
        Peter Zijlstra <peterz@...radead.org>, luto@...nel.org,
        oneukum@...e.com, jroedel@...e.de,
        Matthew Wilcox <willy@...radead.org>,
        David Rientjes <rientjes@...gle.com>,
        Mina Almasry <almasrymina@...gle.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        anshuman.khandual@....com, Michal Hocko <mhocko@...e.com>,
        "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>,
        Xiongchun duan <duanxiongchun@...edance.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        linux-doc@...r.kernel.org,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [External] Re: [PATCH v7 00/15] Free some vmemmap pages of
 hugetlb page

On Fri, Dec 04, 2020 at 11:39:31AM +0800, Muchun Song wrote:
> On Fri, Dec 4, 2020 at 7:49 AM Mike Kravetz <mike.kravetz@...cle.com> 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