+ hugetlb-add-cond_resched-to-__unmap_hugepage_range.patch added to mm-unstable branch
Andrew Morton <[email protected]>
| Newsgroups | org.kernel.vger.mm-commits,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
The patch titled
Subject: hugetlb: add cond_resched() to __unmap_hugepage_range()
has been added to the -mm mm-unstable branch. Its filename is
hugetlb-add-cond_resched-to-__unmap_hugepage_range.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/hugetlb-add-cond_resched-to-__unmap_hugepage_range.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Leon Hwang <[email protected]>
Subject: hugetlb: add cond_resched() to __unmap_hugepage_range()
Date: Tue, 18 Aug 2026 21:50:29 +0800
Packet receive timeouts were traced to sparse HugeTLB unmapping in
production. A task unmapping a sparse 2.5 TiB HugeTLB mapping could
remain in kernel context for over 40 ms without reaching a scheduling
point while walking empty huge PTEs. Although hard IRQs could still be
handled, the per-CPU ksoftirqd thread and other runnable tasks could not
run during that interval, delaying NET_RX softirq work queued to
ksoftirqd.
Add cond_resched() at the beginning of the hugepage loop so ksoftirqd and
other runnable tasks can run between iterations. Testing with
PREEMPT_NONE showed that the maximum interval between scheduling points
fell from over 40 ms to below 2.5 ms. Total time spent in
__unmap_hugepage_range() remained about 36 ms.
Link: https://lore.kernel.org/[email protected]
Signed-off-by: Leon Hwang <[email protected]>
Reported-by: Lance Yang <[email protected]>
Tested-by: Lance Yang <[email protected]>
Cc: David Hildenbrand <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Muchun Song <[email protected]>
Cc: Oscar Salvador <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
mm/hugetlb.c | 2 ++
1 file changed, 2 insertions(+)
--- a/mm/hugetlb.c~hugetlb-add-cond_resched-to-__unmap_hugepage_range
+++ a/mm/hugetlb.c
@@ -5235,6 +5235,8 @@ void __unmap_hugepage_range(struct mmu_g
last_addr_mask = hugetlb_mask_last_page(h);
address = start;
for (; address < end; address += sz) {
+ cond_resched();
+
ptep = hugetlb_walk(vma, address, sz);
if (!ptep) {
address |= last_addr_mask;
_
Patches currently in -mm which might be from [email protected] are
hugetlb-add-cond_resched-to-__unmap_hugepage_range.patch