Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support

On Wed, Jun 03, 2026 at 10:05:08AM +0200, David Hildenbrand (Arm) wrote:

On 6/2/26 17:44, Lance Yang wrote:

quoted

On 2026/6/2 18:58, Nico Pache wrote:

quoted

On Sun, May 31, 2026 at 1:19 AM Lance Yang [off-list ref] wrote:

quoted

[...]

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?

Ok I did the error propagation! I think I handled both of these cases
you brought up pretty easily.

Thanks.

quoted

However I don't know what to do in the following case: We successfully
collapsed some portion of the PMD, but during that process, we also
hit an allocation failure. Is it best to back off entirely? or can we
treat some forward progress as a sign we can continue trying collapses
without sleeping.

Basically, do we prioritize SCAN_ALLOC_HUGE_PAGE_FAIL or the
successful collapses as the returned value?

Thinking out loud, forward progress should win here, the allocation
failure only matter if we made no progress at all?

Agreed, in the first approach, forward progress makes sense.

Sounds sensible to me.

--
Cheers,

David

Thanks, Lorenzo