From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: David Hildenbrand <david@kernel.org>, Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>,
Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Subject: [PATCH v2 2/3] mm/khugepaged: scan mm's more efficiently under mmap_lock contention
Date: Thu, 05 Nov 2026 20:57:23 +0000 [thread overview]
Message-ID: <20261105-khugepaged-latency-fix-v2-2-4384bbfe4606@kernel.org> (raw)
In-Reply-To: <20261105-khugepaged-latency-fix-v2-0-4384bbfe4606@kernel.org>
khugepaged scans VMAs in collapse_scan_mm_slot() in the same mm until it is
about to be torn down, prctl(PR_SET_THP_DISABLE) disables THP for it,
mm->mmap_lock contention occurs, or all its VMAs have been scanned.
When lock contention causes the function to bail out, khugepaged doesn't
keep track of where it left off, so when the mm is next scanned, it starts
from address 0 again.
If there's a lot of mmap_lock contention this can significantly slow down
collapse later in the mm, since the /sys/.../pages_to_scan budget can run
out before the end of the mm is reached.
The budget is incremented (as tracked in cc->progress) at a rate of 1 page
per ineligible VMA, but the budget is only checked once eligible VMAs are
encountered.
Then, it only takes the combined total of ineligible VMAs and eligible but
non-collapsible pages to exceed the /sys/.../pages_to_scan budget for the
rest of the mm to be skipped.
For a system with 4 KiB page size and default sysctl settings this only
requires 4096 ineligible VMAs/uncollapsible pages to be skipped before this
happens.
Resolve the issue by simply tracking the last examined address in the
khugepaged_mm_slot object, so when the mm is resumed, the scan starts from
where it left off.
Additionally, skip to the next candidate if a VMA cannot be collapsed.
This issue was noticed during some work in which an mm was instantiated
with a large number of small VMAs under significant mmap_lock contention,
during which collapse was observed to take 10.8s. With this patch applied
it took 3.6s to collapse the same mm.
Also, while here, update a couple VM_BUG_ON()'s to VM_WARN_ON_ONCE()'s.
This patch is also a prerequisite for the next patch in the series.
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Lance Yang <lance.yang@linux.dev>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
mm/khugepaged.c | 38 ++++++++++++++++++++------------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index aad8797f8d5a..216c4b8d28c4 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -69,23 +69,23 @@ static struct kmem_cache *mm_slot_cache __ro_after_init;
/**
* struct khugepaged_mm_slot - khugepaged information per mm that is being scanned
* @slot: hash lookup from mm to mm_slot
+ * @address: the next address inside that to be scanned
*/
struct khugepaged_mm_slot {
struct mm_slot slot;
+ unsigned long address;
};
/**
* struct khugepaged_scan - cursor for scanning
* @mm_head: the head of the mm list to scan
* @mm_slot: the current mm_slot we are scanning
- * @address: the next address inside that to be scanned
*
* There is only the one khugepaged_scan instance of this cursor structure.
*/
struct khugepaged_scan {
struct list_head mm_head;
struct khugepaged_mm_slot *mm_slot;
- unsigned long address;
};
static struct khugepaged_scan khugepaged_scan = {
@@ -2921,7 +2921,6 @@ static void collapse_scan_mm_slot(unsigned int progress_max,
slot = list_first_entry(&khugepaged_scan.mm_head,
struct mm_slot, mm_node);
mm_slot = mm_slot_entry(slot, struct khugepaged_mm_slot, slot);
- khugepaged_scan.address = 0;
khugepaged_scan.mm_slot = mm_slot;
}
spin_unlock(&khugepaged_mm_lock);
@@ -2939,7 +2938,7 @@ static void collapse_scan_mm_slot(unsigned int progress_max,
if (unlikely(collapse_test_exit_or_disable(mm)))
goto breakouterloop;
- vma_iter_init(&vmi, mm, khugepaged_scan.address);
+ vma_iter_init(&vmi, mm, mm_slot->address);
for_each_vma(vmi, vma) {
unsigned long hstart, hend;
@@ -2948,38 +2947,38 @@ static void collapse_scan_mm_slot(unsigned int progress_max,
cc->progress++;
break;
}
- if (!collapse_possible_orders(vma, vma->vm_flags,
- TVA_KHUGEPAGED)) {
+ if (!collapse_possible_orders(vma, vma->vm_flags, TVA_KHUGEPAGED)) {
+ /* Unable to collapse, skip to the next candidate. */
+ mm_slot->address = ALIGN(vma->vm_end, HPAGE_PMD_SIZE);
cc->progress++;
continue;
}
hstart = ALIGN(vma->vm_start, HPAGE_PMD_SIZE);
hend = ALIGN_DOWN(vma->vm_end, HPAGE_PMD_SIZE);
- if (khugepaged_scan.address > hend) {
+ if (mm_slot->address > hend) {
cc->progress++;
continue;
}
- if (khugepaged_scan.address < hstart)
- khugepaged_scan.address = hstart;
- VM_BUG_ON(khugepaged_scan.address & ~HPAGE_PMD_MASK);
+ if (mm_slot->address < hstart)
+ mm_slot->address = hstart;
+ VM_WARN_ON_ONCE(mm_slot->address & ~HPAGE_PMD_MASK);
- while (khugepaged_scan.address < hend) {
+ while (mm_slot->address < hend) {
bool lock_dropped = false;
cond_resched();
if (unlikely(collapse_test_exit_or_disable(mm)))
goto breakouterloop;
- VM_WARN_ON_ONCE(khugepaged_scan.address < hstart ||
- khugepaged_scan.address + HPAGE_PMD_SIZE >
- hend);
+ VM_WARN_ON_ONCE(mm_slot->address < hstart ||
+ mm_slot->address + HPAGE_PMD_SIZE > hend);
- *result = collapse_single_pmd(khugepaged_scan.address,
+ *result = collapse_single_pmd(mm_slot->address,
vma, &lock_dropped, cc);
if (*result == SCAN_SUCCEED)
khugepaged_pages_collapsed++;
/* move to next address */
- khugepaged_scan.address += HPAGE_PMD_SIZE;
+ mm_slot->address += HPAGE_PMD_SIZE;
if (lock_dropped)
/*
* We released mmap_lock so break loop. Note
@@ -2993,12 +2992,16 @@ static void collapse_scan_mm_slot(unsigned int progress_max,
goto breakouterloop;
}
}
+ /* Every VMA has been examined, so reset. */
+ if (!vma)
+ mm_slot->address = 0;
+
breakouterloop:
mmap_read_unlock(mm); /* exit_mmap will destroy ptes after this */
breakouterloop_mmap_lock:
spin_lock(&khugepaged_mm_lock);
- VM_BUG_ON(khugepaged_scan.mm_slot != mm_slot);
+ VM_WARN_ON_ONCE(khugepaged_scan.mm_slot != mm_slot);
/*
* Release the current mm_slot if this mm is about to die, or
* if we scanned all vmas of this mm, or THP got disabled.
@@ -3013,7 +3016,6 @@ static void collapse_scan_mm_slot(unsigned int progress_max,
slot = list_next_entry(slot, mm_node);
khugepaged_scan.mm_slot =
mm_slot_entry(slot, struct khugepaged_mm_slot, slot);
- khugepaged_scan.address = 0;
} else {
khugepaged_scan.mm_slot = NULL;
khugepaged_full_scans++;
--
2.56.0
next prev parent reply other threads:[~2026-11-05 20:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 20:57 [PATCH v2 0/3] mm/khugepaged: bound mmap_lock hold time when walking an mm's VMAs Lorenzo Stoakes (ARM)
2026-11-05 20:57 ` [PATCH v2 1/3] Revert "mm/khugepaged: remove definition of struct khugepaged_mm_slot" Lorenzo Stoakes (ARM)
2026-11-05 21:47 ` Jose A. Perez de Azpillaga
2026-11-06 9:41 ` Baolin Wang
2026-11-05 20:57 ` Lorenzo Stoakes (ARM) [this message]
2026-11-05 21:48 ` [PATCH v2 2/3] mm/khugepaged: scan mm's more efficiently under mmap_lock contention Jose A. Perez de Azpillaga
2026-11-06 9:31 ` Baolin Wang
2026-11-05 20:57 ` [PATCH v2 3/3] mm/khugepaged: release contended mmap read lock after scanning enough VMAs Lorenzo Stoakes (ARM)
2026-11-05 21:53 ` Jose A. Perez de Azpillaga
2026-11-06 10:03 ` Lorenzo Stoakes (ARM)
2026-11-06 10:29 ` Jose A. Perez de Azpillaga
2026-11-06 10:33 ` Lorenzo Stoakes (ARM)
2026-11-06 10:49 ` Jose A. Perez de Azpillaga
2026-11-06 2:12 ` Vernon Yang
2026-11-06 9:29 ` Vernon Yang
2026-11-06 10:49 ` Lorenzo Stoakes (ARM)
2026-11-06 9:38 ` Baolin Wang
2026-11-06 10:52 ` Lorenzo Stoakes (ARM)
2026-11-06 12:07 ` Lorenzo Stoakes (ARM)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261105-khugepaged-latency-fix-v2-2-4384bbfe4606@kernel.org \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nico.pache@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=usama.arif@linux.dev \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®