Re: [PATCH] hugetlb: add cond_resched() to __unmap_hugepage_range()

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 18 Aug 2026 16:23:29 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:

> On 8/18/26 15:50, Leon Hwang wrote:
> > 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.
> > 
> > Reported-by: Lance Yang <lance.yang@linux.dev>
> > Tested-by: Lance Yang <lance.yang@linux.dev>

Is there a Link: to Lance's report?

> > Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
> > ---
> >  mm/hugetlb.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index dded1768193a..0a91aac2369f 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -5233,6 +5233,8 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
> >  	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;
> 
> As Michal just put it:
> 
> "PREEMPT_NONE is effectivelly dead and most cond_resched will/should be
> removed. Is there any reason why you are not using full preemption when
> requiring low latencies?"
> 
> https://lore.kernel.org/r/aoRnUxUlgf_kRlm8@tiehlicka

That's pretty bad behavior and we might want to fix it in earlier
kernels.  Is PREEMPT_NONE effectively dead in 6.18.x and its
existing users?

If yes, we do want to fix older kernels then we should merge this.