[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0b711878-71b0-4a4b-4f0b-af157d6cac42@oracle.com>
Date: Mon, 9 Jan 2023 10:36:44 -0600
From: Sidhartha Kumar <sidhartha.kumar@...cle.com>
To: Mike Kravetz <mike.kravetz@...cle.com>,
Matthew Wilcox <willy@...radead.org>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
akpm@...ux-foundation.org, songmuchun@...edance.com,
tsahu@...ux.ibm.com, jhubbard@...dia.com
Subject: Re: [PATCH mm-unstable 8/8] mm/hugetlb: convert demote_free_huge_page
to folios
On 1/7/23 2:55 PM, Mike Kravetz wrote:
> On 01/07/23 01:31, Matthew Wilcox wrote:
>> On Fri, Jan 06, 2023 at 05:11:36PM -0800, Mike Kravetz wrote:
>>> On 01/03/23 13:13, Sidhartha Kumar wrote:
>>>> @@ -3477,15 +3477,15 @@ static int demote_free_huge_page(struct hstate *h, struct page *page)
>>>> mutex_lock(&target_hstate->resize_lock);
>>>> for (i = 0; i < pages_per_huge_page(h);
>>>> i += pages_per_huge_page(target_hstate)) {
>>>> - subpage = nth_page(page, i);
>>>> - folio = page_folio(subpage);
>>>> + subpage = folio_page(folio, i);
>>>> + subfolio = page_folio(subpage);
>>>
>>> No problems with the code, but I am not in love with the name subfolio.
>>> I know it is patterned after 'subpage'. For better or worse, the term
>>> subpage is used throughout the kernel. This would be the first usage of
>>> the term 'subfolio'.
>>>
>>> Matthew do you have any comments on the naming? It is local to hugetlb,
>>> but I would hate to see use of the term subfolio based on its introduction
>>> here.
>>
>> I'm really not a fan of it either. I intended to dive into this patch
>> and understand the function it's modifying, in the hopes of suggesting
>> a better name and/or method.
>
> At a high level, this routine is splitting a very large folio (1G for
> example) into multiple large folios of a smaller size (512 2M folios for
> example). The loop is iterating through the very large folio at
> increments of the smaller large folio. subfolio (previously subpage) is
> used to point to the smaller large folio within the loop.
>
If folio does not need to be part of the variable name, how about
something like 'demote_target'? The prep call inside the loop would then
look like:
prep_new_hugetlb_folio(target_hstate, demote_target, nid);
so it is still clear that demote_target is a folio. A more concise
version could also be 'demote_dst' but that seems more ambiguous than
target.
Thanks,
Sidhartha Kumar
Powered by blists - more mailing lists