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

+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)" <[email protected]> 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