Re: [PATCH mm-unstable v15 06/13] mm/khugepaged: skip collapsing mTHP to smaller orders
From: David Hildenbrand (Arm)
Date: Mon Apr 13 2026 - 03:44:32 EST
On 4/13/26 03:38, Nico Pache wrote:
> On Thu, Mar 12, 2026 at 3:00 PM David Hildenbrand (Arm)
> <david@xxxxxxxxxx> wrote:
>>
>> On 2/26/26 04:24, Nico Pache wrote:
>>> khugepaged may try to collapse a mTHP to a smaller mTHP, resulting in
>>> some pages being unmapped. Skip these cases until we have a way to check
>>> if its ok to collapse to a smaller mTHP size (like in the case of a
>>> partially mapped folio).
>>>
>>> This patch is inspired by Dev Jain's work on khugepaged mTHP support [1].
>>>
>>> [1] https://lore.kernel.org/lkml/20241216165105.56185-11-dev.jain@xxxxxxx/
>>>
>>> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
>>> Reviewed-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>
>>> Co-developed-by: Dev Jain <dev.jain@xxxxxxx>
>>> Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
>>> Signed-off-by: Nico Pache <npache@xxxxxxxxxx>
>>> ---
>>> mm/khugepaged.c | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>> index fb3ba8fe5a6c..c739f26dd61e 100644
>>> --- a/mm/khugepaged.c
>>> +++ b/mm/khugepaged.c
>>> @@ -638,6 +638,14 @@ static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma,
>>> goto out;
>>> }
>>> }
>>> + /*
>>> + * TODO: In some cases of partially-mapped folios, we'd actually
>>> + * want to collapse.
>>> + */
>>> + if (!is_pmd_order(order) && folio_order(folio) >= order) {
>>> + result = SCAN_PTE_MAPPED_HUGEPAGE;
>>> + goto out;
>>> + }
>>>
>>> if (folio_test_large(folio)) {
>>> struct folio *f;
>>
>> Why aren't we doing the same in hpage_collapse_scan_pmd() ?
>
> We can't do this in the scan phase because we are not yet aware of the
> order we want to collapse to.
Yes, realized that myself later. It's confusing, try documenting that in
the patch description.
--
Cheers,
David