linux-kernel - Re: [External] Re: [PATCH v23 6/9] mm: hugetlb: alloc the vmemmap pages associated with each 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 for Android: free password hash cracker in your pocket

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

Message-ID: <188b3f52-05d7-7fe8-70e0-88009d7d70b8@oracle.com>
Date:   Mon, 10 May 2021 18:10:40 -0700
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Muchun Song <songmuchun@...edance.com>,
        Oscar Salvador <osalvador@...e.de>
Cc:     Jonathan Corbet <corbet@....net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, bp@...en8.de,
        X86 ML <x86@...nel.org>, hpa@...or.com,
        dave.hansen@...ux.intel.com, luto@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>, paulmck@...nel.org,
        pawan.kumar.gupta@...ux.intel.com,
        Randy Dunlap <rdunlap@...radead.org>, oneukum@...e.com,
        anshuman.khandual@....com, jroedel@...e.de,
        Mina Almasry <almasrymina@...gle.com>,
        David Rientjes <rientjes@...gle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Michal Hocko <mhocko@...e.com>,
        "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>,
        David Hildenbrand <david@...hat.com>,
        HORIGUCHI NAOYA(堀口 直也) 
        <naoya.horiguchi@....com>,
        Joao Martins <joao.m.martins@...cle.com>,
        Xiongchun duan <duanxiongchun@...edance.com>,
        fam.zheng@...edance.com, zhengqi.arch@...edance.com,
        linux-doc@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [External] Re: [PATCH v23 6/9] mm: hugetlb: alloc the vmemmap
 pages associated with each HugeTLB page

On 5/10/21 5:19 AM, Muchun Song wrote:
> On Mon, May 10, 2021 at 6:45 PM Oscar Salvador <osalvador@...e.de> wrote:
>>
>> On Mon, May 10, 2021 at 11:00:24AM +0800, Muchun Song wrote:
>>> --- a/mm/hugetlb.c
>>> +++ b/mm/hugetlb.c
>>> @@ -1376,6 +1376,39 @@ static void remove_hugetlb_page(struct hstate *h, struct page *page,
>>>       h->nr_huge_pages_node[nid]--;
>>>  }
>>>
>>> +static void add_hugetlb_page(struct hstate *h, struct page *page,
>>> +                          bool adjust_surplus)
>>> +{
<snip>
>>
>> I think this function would benefit from some renaming. add_hugetlb_page() gives
>> me no hint of what is this about, although I can figure it out reading the code.
> 
> Because I think it is the reverse operation of remove_hugetlb_page,
> I named it add_hugetlb_page. Do you have any suggestions for
> renaming?
> 

FWIW, I am fine with the naming.  As Muchun mentions, it is the opposite
of remove_hugetlb_page.  At one time, I created a function with the same
name to be used by set_max_huge_pages and other routines which add pages
to the hugetlb pool.  It would be much more obvious than the current
code path in which we call put_page which calls the hugetlb destructor
free_huge_page to add the page to the pool.
-- 
Mike Kravetz