Re: [PATCH] mm/compaction: fix low_pfn advance on isolating hugetlb

[Wei Yang <richard.weiyang@gmail.com>]

On Wed, Sep 10, 2025 at 09:50:09PM -0400, Zi Yan wrote:
>On 10 Sep 2025, at 21:38, Zi Yan wrote:
>
>> On 10 Sep 2025, at 21:35, Zi Yan wrote:
>>
>>> On 10 Sep 2025, at 21:25, Wei Yang wrote:
>>>
>>>> On Wed, Sep 10, 2025 at 09:22:40AM +0000, Wei Yang wrote:
>>>>> Commit 56ae0bb349b4 ("mm: compaction: convert to use a folio in
>>>>> isolate_migratepages_block()") converts api from page to folio. But the
>>>>> low_pfn advance for hugetlb page seems wrong when low_pfn doesn't point
>>>>> to head page.
>>>>>
>>>>> Originally, if page is a hugetlb tail page, compound_nr() return 1,
>>>>> which means low_pfn only advance one in next iteration. After the
>>>>> change, low_pfn would advance more than the hugetlb range, since
>>>>> folio_nr_pages() always return total number of the large page. This
>>>>> results in skipping some range to isolate and then to migrate.
>>>>>
>>>>> The worst case for alloc_contig is it does all the isolation and
>>>>> migration, but finally find some range is still not isolated. And then
>>>>> undo all the work and try a new range.
>>>>>
>>>>> Advance low_pfn to the end of hugetlb.
>>>>>
>>>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>>>>> Fixes: 56ae0bb349b4 ("mm: compaction: convert to use a folio in isolate_migratepages_block()")
>
>This behavior seems to be introduced by commit 369fa227c219 ("mm: make
>alloc_contig_range handle free hugetlb pages”). The related change is:
>
>+               if (PageHuge(page) && cc->alloc_contig) {
>+                       ret = isolate_or_dissolve_huge_page(page);
>+
>+                       /*
>+                        * Fail isolation in case isolate_or_dissolve_huge_page()
>+                        * reports an error. In case of -ENOMEM, abort right away.
>+                        */
>+                       if (ret < 0) {
>+                                /* Do not report -EBUSY down the chain */
>+                               if (ret == -EBUSY)
>+                                       ret = 0;
>+                               low_pfn += (1UL << compound_order(page)) - 1;

The compound_order(page) return 1 for a tail page.

See below.

>+                               goto isolate_fail;
>+                       }
>+
>+                       /*
>+                        * Ok, the hugepage was dissolved. Now these pages are
>+                        * Buddy and cannot be re-allocated because they are
>+                        * isolated. Fall-through as the check below handles
>+                        * Buddy pages.
>+                        */
>+               }
>+
>
>>>>> Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
>>>>> Cc: Oscar Salvador <osalvador@suse.de>
>>>>
>>>> Forgot to cc stable.
>>>>
>>>> Cc: <stable@vger.kernel.org>
>>>
>>> Is there any bug report to justify the backport? Since it is more likely
>>> to be a performance issue instead of a correctness issue.
>>>
>>>>
>>>>> ---
>>>>> mm/compaction.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/mm/compaction.c b/mm/compaction.c
>>>>> index bf021b31c7ec..1e8f8eca318c 100644
>>>>> --- a/mm/compaction.c
>>>>> +++ b/mm/compaction.c
>>>>> @@ -989,7 +989,7 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
>>>>> 				 * Hugepage was successfully isolated and placed
>>>>> 				 * on the cc->migratepages list.
>>>>> 				 */
>>>>> -				low_pfn += folio_nr_pages(folio) - 1;
>>>>> +				low_pfn += folio_nr_pages(folio) - folio_page_idx(folio, page) - 1;
>>>>
>>>> One question is why we advance compound_nr() in original version.
>>>>
>>>> Yes, there are several places advancing compound_nr(), but it seems to iterate
>>>> on the same large page and do the same thing and advance 1 again.
>>>>
>>>> Not sure which part story I missed.
>>>
>>> isolate_migratepages_block() starts from the beginning of a pageblock.
>>> How likely the code hit in the middle of a hugetlb?
>>>
>>
>> In addition, there are two other “low_pfn += (1UL << order) - 1”
>> in the if (PageHuge(page)), why not change them too if you think
>> page can point to the middle of a hugetlb?
>>

The order here is get from compound_order(page), which is 1 for a tail page.

So it looks right. Maybe I misunderstand it?

>> Best Regards,
>> Yan, Zi
>
>
>Best Regards,
>Yan, Zi

-- 
Wei Yang
Help you, Help me