Re: [RFC v2 9/9] khugepaged: skip collapsing mTHP to smaller orders
From: Ryan Roberts <ryan.roberts@arm.com>
Date: 2025-02-19 16:57:42
Also in:
linux-mm, lkml
On 11/02/2025 00:30, Nico Pache wrote:
quoted hunk ↗ jump to hunk
khugepaged may try to collapse a mTHP to a smaller mTHP, resulting in some pages being unmapped. 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 patch is inspired by Dev Jain's work on khugepaged mTHP support [1]. [1] https://lore.kernel.org/lkml/20241216165105.56185-11-dev.jain@arm.com/ (local) Signed-off-by: Nico Pache <redacted> --- mm/khugepaged.c | 5 +++++ 1 file changed, 5 insertions(+)diff --git a/mm/khugepaged.c b/mm/khugepaged.c index e2ba18e57064..fc30698b8e6e 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c@@ -622,6 +622,11 @@ static int __collapse_huge_page_isolate(struct vm_area_struct *vma, folio = page_folio(page); VM_BUG_ON_FOLIO(!folio_test_anon(folio), folio); + if (order != HPAGE_PMD_ORDER && folio_order(folio) >= order) { + result = SCAN_PTE_MAPPED_HUGEPAGE; + goto out; + }
One of the key areas where we want to benefit from khugepaged collapsing to mTHP is when a COW event happens. If the original folio was large, then it becomes partially mapped due to COW and we want to collapse it again. I think this will prevent that? I made some fairly detailed suggestions for what I think is the right approach in the context of Dev's series. It would be good to get your thoughts on that: https://lore.kernel.org/lkml/aa647830-cf55-48f0-98c2-8230796e35b3@arm.com/ (local) Thanks, Ryan
+
/* See khugepaged_scan_pmd(). */
if (folio_likely_mapped_shared(folio)) {
++shared;