linux-kernel - Re: [PATCH v13 mm-new 05/16] khugepaged: introduce is_mthp

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] [day] [month] [year] [list]

Message-ID: <8676CDC6-02E7-4676-A619-C9E776751C13@nvidia.com>
Date: Tue, 13 Jan 2026 21:49:19 -0500
From: Zi Yan <ziy@...dia.com>
To: Nico Pache <npache@...hat.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 linux-mm@...ck.org, linux-doc@...r.kernel.org, david@...hat.com,
 baolin.wang@...ux.alibaba.com, Liam.Howlett@...cle.com, ryan.roberts@....com,
 dev.jain@....com, corbet@....net, rostedt@...dmis.org, mhiramat@...nel.org,
 mathieu.desnoyers@...icios.com, akpm@...ux-foundation.org, baohua@...nel.org,
 willy@...radead.org, peterx@...hat.com, wangkefeng.wang@...wei.com,
 usamaarif642@...il.com, sunnanyong@...wei.com, vishal.moola@...il.com,
 thomas.hellstrom@...ux.intel.com, yang@...amperecomputing.com,
 kas@...nel.org, aarcange@...hat.com, raquini@...hat.com,
 anshuman.khandual@....com, catalin.marinas@....com, tiwai@...e.de,
 will@...nel.org, dave.hansen@...ux.intel.com, jack@...e.cz, cl@...two.org,
 jglisse@...gle.com, surenb@...gle.com, zokeefe@...gle.com,
 hannes@...xchg.org, rientjes@...gle.com, mhocko@...e.com,
 rdunlap@...radead.org, hughd@...gle.com, richard.weiyang@...il.com,
 lance.yang@...ux.dev, vbabka@...e.cz, rppt@...nel.org, jannh@...gle.com,
 pfalcato@...e.de
Subject: Re: [PATCH v13 mm-new 05/16] khugepaged: introduce is_mthp_order
 helper

On 13 Jan 2026, at 21:38, Nico Pache wrote:

> On Tue, Dec 2, 2025 at 8:13 PM Zi Yan <ziy@...dia.com> wrote:
>>
>> On 1 Dec 2025, at 12:46, Nico Pache wrote:
>>
>>> In order to add mTHP support, we will often be checking if a given order
>>> is a mTHP or PMD order. Lets create a simple helper function to keep the
>>> code clean and readable.
>>>
>>> Suggested-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
>>> Signed-off-by: Nico Pache <npache@...hat.com>
>>> ---
>>>  mm/khugepaged.c | 9 +++++++--
>>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>> index 8599c7fa112e..9c041141b2e3 100644
>>> --- a/mm/khugepaged.c
>>> +++ b/mm/khugepaged.c
>>> @@ -338,6 +338,11 @@ static bool pte_none_or_zero(pte_t pte)
>>>       return pte_present(pte) && is_zero_pfn(pte_pfn(pte));
>>>  }
>>>
>>> +static bool is_mthp_order(unsigned int order)
>>> +{
>>> +     return order != HPAGE_PMD_ORDER;
>>> +}
>>> +
>>
>> The code at the bottom of __folio_split() in mm/huge_memory.c
>> can use this helper.
>>
>> The code in deferred_split_folio() uses folio_test_pmd_mappable()
>> instead of order == HPAGE_PMD_ORDER, but the code can be changed
>> to use the helper.
>
> static inline bool folio_test_pmd_mappable(struct folio *folio)
> {
> return folio_order(folio) >= HPAGE_PMD_ORDER;
> }
>
> Should we make the is_mthp_order() check all orders that are less than
> HPAGE_PMD_ORDER.
>
> ie)
>
> +static bool is_mthp_order(unsigned int order)
> +{
> +     return order < HPAGE_PMD_ORDER;
> }
>
> This way it's true to its mTHP nature being smaller than the PMD.

I am not sure. It really depends on in the future whether we call
> 9 order (can be mapped by multiple PMDs) large folio mTHP or not.
My current feeling is that THP is a legacy name for PMD THP and
any other large folios are mTHP. So your current definition of
is_mthp_order() looks right to me. This is just my feeling and
I am open to other opinions.

folio_test_pmd_mappable() is different, since as long as a folio's
order is greater than HPAGE_PMD_ORDER, it indeed can be mapped
by PMDs.

--
Best Regards,
Yan, Zi