Re: [RFC PATCH v2 04/11] mm: khugepaged: add shmem mTHP collapse support
From: Baolin Wang
Date: Mon Jun 15 2026 - 02:47:04 EST
On 6/12/26 6:22 PM, Nico Pache wrote:
On 6/10/26 6:44 AM, Lance Yang wrote:
On Wed, Jun 10, 2026 at 06:29:12PM +0800, Baolin Wang wrote:
[...]
@@ -1512,8 +1517,12 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
enum scan_result ret;
collapse_address = address + offset * PAGE_SIZE;
- ret = collapse_huge_page(mm, collapse_address, referenced,
- unmapped, cc, order);
+ if (file)
+ ret = collapse_file(mm, collapse_address, file,
+ start + offset, cc, order);
+ else
+ ret = collapse_huge_page(mm, collapse_address,
+ referenced, unmapped, cc, order);
switch (ret) {
/* Cases where we continue to next collapse candidate */
@@ -1521,6 +1530,7 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
collapsed += nr_ptes;
fallthrough;
case SCAN_PTE_MAPPED_HUGEPAGE:
Looks like SCAN_PTE_MAPPED_HUGEPAGE from collapse_file() get lost for
the PMD-order case.
This is kinda my fault... I reused the enum PTE_MAPPED_HUGEPAGE (which was only
really used in file collapse) when reporting that a collapse attempts is smaller
or equal to the current order of the folio.
if (!is_pmd_order(order) && folio_order(folio) >= order) {
I will change that in my follow up to use its own (or a different enum).
Maybe use SCAN_PAGE_COMPOUND? Anyway, I’ve already fixed the issue Lance raised locally.