khugepaged may try to collapse a mTHP to a folio of equal or smaller size,
possibly resulting in a partially mapped source folio, which is undesired.
Skip these cases until we have a way to check if its ok to collapse to a
smaller mTHP size (like in the case of a partially mapped folio). This
check is not done during the scan phase as the current collapse order is
unknown at that time.

This patch is inspired by Dev Jain's work on khugepaged mTHP support [1].

[1] https://lore.kernel.org/lkml/[email protected]/

Reviewed-by: Lorenzo Stoakes <[email protected]>
Reviewed-by: Baolin Wang <[email protected]>
Acked-by: David Hildenbrand (arm) <[email protected]>
Acked-by: Usama Arif <[email protected]>
Co-developed-by: Dev Jain <[email protected]>
Signed-off-by: Dev Jain <[email protected]>
Signed-off-by: Nico Pache <[email protected]>
---
 mm/khugepaged.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index c2769d82a719..191e529c185c 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -697,6 +697,14 @@ static enum scan_result 
__collapse_huge_page_isolate(struct vm_area_struct *vma,
                                goto out;
                        }
                }
+               /*
+                * TODO: In some cases of partially-mapped folios, we'd actually
+                * want to collapse.
+                */
+               if (!is_pmd_order(order) && folio_order(folio) >= order) {
+                       result = SCAN_PTE_MAPPED_HUGEPAGE;
+                       goto out;
+               }
 
                if (folio_test_large(folio)) {
                        struct folio *f;
-- 
2.54.0


Reply via email to