+ 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.