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 <[email protected]> > > Thanks! -- Best Regards, Yan, Zi
