[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

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

[Andrew Morton]

On Wed, 19 Aug 2026 06:18:58 +0800 Lance Yang <lance.yang@linux.dev> wrote:

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

I think so - as long as PREEPMT_NONE exists we should support it as
well as we can.  If the day comes that PREEMPT_NONE is removed, then we
get to remove lots of cond_resched()s.  mm/ has 200 of the things.

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

Addressing this issue in older kernels is another reason.

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

[Matthew Wilcox]

On Tue, Aug 18, 2026 at 04:24:30PM -0700, Andrew Morton wrote:
> On Wed, 19 Aug 2026 06:18:58 +0800 Lance Yang <lance.yang@linux.dev> wrote:
> 
> > >> > 
> > >> > 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?
> 
> I think so - as long as PREEPMT_NONE exists we should support it as
> well as we can.  If the day comes that PREEMPT_NONE is removed, then we
> get to remove lots of cond_resched()s.  mm/ has 200 of the things.
> 
> > Mainline scheduling stays unchanged, and stable can pick it up for old
> > PREEMPT_NONE kernels. wdyt?
> 
> Addressing this issue in older kernels is another reason.

That is not the direction that the scheduler developers wish us to take.

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

[Andrew Morton]

On Wed, 19 Aug 2026 00:46:09 +0100 Matthew Wilcox <willy@infradead.org> wrote:

> On Tue, Aug 18, 2026 at 04:24:30PM -0700, Andrew Morton wrote:
> > On Wed, 19 Aug 2026 06:18:58 +0800 Lance Yang <lance.yang@linux.dev> wrote:
> > 
> > > >> > 
> > > >> > 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?
> > 
> > I think so - as long as PREEPMT_NONE exists we should support it as
> > well as we can.  If the day comes that PREEMPT_NONE is removed, then we
> > get to remove lots of cond_resched()s.  mm/ has 200 of the things.
> > 
> > > Mainline scheduling stays unchanged, and stable can pick it up for old
> > > PREEMPT_NONE kernels. wdyt?
> > 
> > Addressing this issue in older kernels is another reason.
> 
> That is not the direction that the scheduler developers wish us to take.

Well back luck.

"Packet receive timeouts were traced to sparse HugeTLB unmapping in
production".  Do sched developers have a proposal to fix that in
year-old kernels?

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

[Michal Hocko]

On Tue 18-08-26 16:59:38, Andrew Morton wrote:
> On Wed, 19 Aug 2026 00:46:09 +0100 Matthew Wilcox <willy@infradead.org> wrote:
> 
> > On Tue, Aug 18, 2026 at 04:24:30PM -0700, Andrew Morton wrote:
> > > On Wed, 19 Aug 2026 06:18:58 +0800 Lance Yang <lance.yang@linux.dev> wrote:
> > > 
> > > > >> > 
> > > > >> > 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?
> > > 
> > > I think so - as long as PREEPMT_NONE exists we should support it as
> > > well as we can.  If the day comes that PREEMPT_NONE is removed, then we
> > > get to remove lots of cond_resched()s.  mm/ has 200 of the things.
> > > 
> > > > Mainline scheduling stays unchanged, and stable can pick it up for old
> > > > PREEMPT_NONE kernels. wdyt?
> > > 
> > > Addressing this issue in older kernels is another reason.
> > 
> > That is not the direction that the scheduler developers wish us to take.
> 
> Well back luck.
> 
> "Packet receive timeouts were traced to sparse HugeTLB unmapping in
> production".  Do sched developers have a proposal to fix that in
> year-old kernels?

Yes, do not use PREEMPT_NONE in anything that is latency sensitive.
It makes very little sense to add more cond_resched, just to be
removed later.
-- 
Michal Hocko
SUSE Labs

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

[David Hildenbrand (Arm)]

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

It's tricky: if a problem only exists in stable (there is nothing to fix in
Linus' tree), then a stable-only fix is acceptable.

Otherwise we'd have to route unnecessary churn through upstream just for it to
reach stable, which doesn't make any sense.

When sending a stable patch, it should document how this is only a stable
problem and why no corresponding upstream fix is required (or how the actual fix
for upstream is actually deprecating the relevant config).

-- 
Cheers,

David

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

[Michal Hocko]

On Wed 19-08-26 09:53:25, David Hildenbrand wrote:
> On 8/18/26 20:55, Andrew Morton wrote:
> > On Tue, 18 Aug 2026 20:21:37 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> > 
> >>>
> >>> 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).
> 
> It's tricky: if a problem only exists in stable (there is nothing to fix in
> Linus' tree), then a stable-only fix is acceptable.

The crucial quiestion is whether this is something that needs a code fix
or a configuration fix. Really fighting for low latencies with
PREEMPT_NONE is a kinda lost battle. You might want to play whack a
mole...

-- 
Michal Hocko
SUSE Labs

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

[David Hildenbrand (Arm)]

On 8/19/26 10:50, Michal Hocko wrote:
> On Wed 19-08-26 09:53:25, David Hildenbrand wrote:
>> On 8/18/26 20:55, Andrew Morton wrote:
>>>
>>>
>>> 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).
>>
>> It's tricky: if a problem only exists in stable (there is nothing to fix in
>> Linus' tree), then a stable-only fix is acceptable.
> 
> The crucial quiestion is whether this is something that needs a code fix
> or a configuration fix. Really fighting for low latencies with
> PREEMPT_NONE is a kinda lost battle. You might want to play whack a
> mole...

Yes, I read your comment on the other thread afterwards and I agree.

The whole reason we added cond_resched() all over the place over the years was
to avoid splats from false detected hung tasks (e.g., 30s ...).

Not to optimize latency in the ms range.

-- 
Cheers,

David

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

[Michal Hocko]

On Wed 19-08-26 10:54:11, David Hildenbrand wrote:
> On 8/19/26 10:50, Michal Hocko wrote:
> > On Wed 19-08-26 09:53:25, David Hildenbrand wrote:
> >> On 8/18/26 20:55, Andrew Morton wrote:
> >>>
> >>>
> >>> 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).
> >>
> >> It's tricky: if a problem only exists in stable (there is nothing to fix in
> >> Linus' tree), then a stable-only fix is acceptable.
> > 
> > The crucial quiestion is whether this is something that needs a code fix
> > or a configuration fix. Really fighting for low latencies with
> > PREEMPT_NONE is a kinda lost battle. You might want to play whack a
> > mole...
> 
> Yes, I read your comment on the other thread afterwards and I agree.
> 
> The whole reason we added cond_resched() all over the place over the years was
> to avoid splats from false detected hung tasks (e.g., 30s ...).
> 
> Not to optimize latency in the ms range.

Exactly, they aimed to provide reasonable upper boundary of
no-preemption with non-preemptive scheduling. And those are on decline
which is a reason to keep bar for adding new ones high and also
optimizing low latencies fundamentally makes no sense for those models.
So even more reason to not add them in these cases. This will just add
more future work when non-preemptive models are gone which will
eventually happen AFAIU.

-- 
Michal Hocko
SUSE Labs