Re: [PATCH 1/2] kselftest: mm: prevent random failure of huge page split for khugepaged
From: Zi Yan
Date: Fri Aug 21 2026 - 10:17:49 EST
On Thu Aug 20, 2026 at 7:55 PM EDT, Yeoreum Yun wrote:
> On Thu, Aug 20, 2026 at 07:37:29PM -0400, Zi Yan wrote:
>> On Thu Aug 20, 2026 at 5:23 PM EDT, Yeoreum Yun wrote:
>> > On Thu, Aug 20, 2026 at 03:51:34PM -0400, Zi Yan wrote:
>> >> On Thu Aug 20, 2026 at 3:40 PM EDT, Yeoreum Yun wrote:
>> >> > There're some random failure for split_huge_page_test when khugepaged
>> >> > collapses pages into pmd again which had split by the test.
>> >> >
>> >> > Prevent the khugepaged's collapses for split page by setting the
>> >> > mapped pmd-huge-page with MADV_NOHUGEPAGE before split.
>> >>
>> >> Why not disable khugepaged using APIs from hugepage_setting.h?
>> >
>> > Well, this also works with hugepage_save_settings() and write the
>> > khugepaged/scan_sleep_millisecs with the maximum integer.
>> >
>> > I don't have a strong opinion but since it seems more hackish way to
>> > change scan_sllep_millisecs, I use madvise() with MADV_NOHUGEPATE.
>> >
>> > Would it be better to change using APIs in hugepage_setting,h?
>>
>> No. I did not realize there is no way of stopping khugepaged completely.
>>
>> BTW, I am curious about your khugepaged config causing this issue.
>> IIRC, khugepaged scan interval is about minutes and
>> the time between madvise(MADV_HUGEPAGE) and the second
>> is_backed_by_folio() should not be that long.
>
> Yes. it's relly timing sensitive and I've failed to reproduce in the
> real hardware. but in the emulation environment it often failed with
> the scan_sllep_millisecs as 10 seconds while the test running.
Oh, it happened in the emulation environment. That makes sense.
>
>>
>> For your patch, maybe you want to check the return value of madvise() to
>> make sure it succeeds.
>
> Yeap. but it seems enough just worning message for the madvise() with
> MADV_NOHUGEPAGE.
Yes, since there are huge page checks right after MADV_HUGEPAGE ones.
>
>>
>> Otherwise,
>>
>> feel free to add
>>
>> Reviewed-by: Zi Yan <ziy@xxxxxxxxxx>
>
> Thanks!
--
Best Regards,
Yan, Zi