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

["David Hildenbrand (Arm)" <david@kernel.org>]

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