Re: [PATCH] hugetlb: add cond_resched() to __unmap_hugepage_range()
Andrew Morton <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 19 Aug 2026 06:18:58 +0800 Lance Yang <[email protected]> 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.