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

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

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?