On Sun, May 31, 2026 at 2:48 AM Lance Yang <[email protected]> wrote: > > > > On 2026/5/31 15:18, Lance Yang wrote: > > > > On Fri, May 22, 2026 at 09:00:06AM -0600, Nico Pache wrote: > > [...] > >> @@ -1587,10 +1749,11 @@ static enum scan_result collapse_scan_pmd(struct > >> mm_struct *mm, > >> if (result == SCAN_SUCCEED) { > >> /* collapse_huge_page expects the lock to be dropped before > >> calling */ > >> mmap_read_unlock(mm); > >> - result = collapse_huge_page(mm, start_addr, referenced, > >> - unmapped, cc, HPAGE_PMD_ORDER); > >> - /* collapse_huge_page will return with the mmap_lock released > >> */ > >> + nr_collapsed = mthp_collapse(mm, vma, start_addr, referenced, > >> + unmapped, cc, enabled_orders); > >> + /* mmap_lock was released above, set lock_dropped */ > >> *lock_dropped = true; > >> + result = nr_collapsed ? SCAN_SUCCEED : SCAN_FAIL; > > > > Hmm ... don't we lose the allocation-failure result here? > > > > Previously collapse_scan_pmd() propagated SCAN_ALLOC_HUGE_PAGE_FAIL from > > collapse_huge_page(), so khugepaged would call khugepaged_alloc_sleep() > > in khugepaged_do_scan(). > > > > Now if allocation fails and nr_collapsed stays 0, we just return > > SCAN_FAIL. So we won't back off via khugepaged_alloc_sleep() anymore? > > Looks like this is a more general issue with mthp_collapse() only > returning nr_collapsed. > > For example, SCAN_PMD_MAPPED used to be propagated too, and > madvise_collapse() treats that as success. With the new code, if > nothing was collapsed by this call, that can also become SCAN_FAIL ... > > So I think we should keep both.
Yeah I thought about this before, but more regarding the "incorrect" propagation of errors; I didn't consider that those results were actually being considered. I actually had a patch to track the last_failure (with some prioritization on certain results). I think that would solve this issue. Thanks for reminding me to improve this. Depending on how the rest of the reviews go, I can either send up a follow up series to do some more cleanups and improvements of the current approach or we can send out a v19. Cheers, -- Nico > > Cheers, Lance >
