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

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

[Leon Hwang]

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>
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;
-- 
2.55.0

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

[David Hildenbrand (Arm)]

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>
> 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

-- 
Cheers,

David

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

[Andrew Morton]

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.

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

[David Hildenbrand (Arm)]

On 8/18/26 20:17, Andrew Morton wrote:
> 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.
> 

Okay, but that would be stable-only fixes?

-- 
Cheers,

David

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

[Andrew Morton]

On Tue, 18 Aug 2026 20:21:37 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:

> >>>  		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.
> > 
> 
> Okay, but that would be stable-only fixes?

Not understanding.

Maybe you refer to adding a patch to -stable but not to -linus?  That's
against the -stable rules
(Documentation/process/stable-kernel-rules.rst).

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

[Lance Yang]

+Cc Michal

On Tue, Aug 18, 2026 at 11:55:26AM -0700, Andrew Morton wrote:
>On Tue, 18 Aug 2026 20:21:37 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
>
>> >>>  		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

Ah, I missed that PREEMPT_LAZY is now the default on major archs and
PREEMPT_NONE is effectively gone there ...

>> > 
>> > 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.
>> > 
>> 
>> Okay, but that would be stable-only fixes?
>
>Not understanding.
>
>Maybe you refer to adding a patch to -stable but not to -linus?  That's
>against the -stable rules
>(Documentation/process/stable-kernel-rules.rst).

Since cond_resched() is a scheduling no-op under LAZY/FULL anyway (only
the __might_resched() debug check remains), why not take this upstream
with Cc: stable?

Mainline scheduling stays unchanged, and stable can pick it up for old
PREEMPT_NONE kernels. wdyt?

Thanks, Lance