Re: [External] Re: [PATCH v23 6/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/10/21 5:19 AM, Muchun Song wrote:
> On Mon, May 10, 2021 at 6:45 PM Oscar Salvador <osalvador@xxxxxxx> 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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux