Re: [PATCH v6.12] sched/fair: Block delayed tasks on throttled hierarchy during dequeue

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Oct 15, 2025 at 09:27:53AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Oct 15, 2025 at 11:57:19AM +0530, K Prateek Nayak wrote:
> > Hello Greg,
> > 
> > On 10/15/2025 11:44 AM, Greg Kroah-Hartman wrote:
> > >> Greg, Sasha,
> > >>
> > >> This fix cleanly applies on top of v6.16.y and v6.17.y stable kernels
> > >> too when cherry-picked from v6.12.y branch (or with 'git am -3'). Let me
> > >> know if you would like me to send a seperate patch for each.
> > >>
> > >> As mentioned above, the upstream fixes this as a part of larger feature
> > >> and we would only like these bits backported. If there are any future
> > >> conflicts in this area during backporting, I would be more than happy to
> > >> help out resolve them.
> > > 
> > > Why not just backport all of the mainline changes instead?  As I say a
> > > lot, whenever we do these "one off" changes, it's almost always wrong
> > > and causes problems over the years going forward as other changes around
> > > the same area can not be backported either.
> > > 
> > > So please, try to just backport the original commits.
> > 
> > Peter was in favor of backporting just the necessary bits in
> > https://lore.kernel.org/all/20250929103836.GK3419281@noisy.programming.kicks-ass.net/
> > 
> > Backporting the whole of per-task throttle feature is lot more heavy
> > handed with the core changes adding:
> > 
> >  include/linux/sched.h |   5 +
> >  kernel/sched/core.c   |   3 +
> >  kernel/sched/fair.c   | 451 ++++++++++++++++++++++++------------------
> >  kernel/sched/pelt.h   |   4 +-
> >  kernel/sched/sched.h  |   7 +-
> >  5 files changed, 274 insertions(+), 196 deletions(-)
> 
> That's very tiny overall in the scheme of what we take for the stable
> trees.
> 
> > And a few more fixes that will add to the above before v6.18. I'll defer
> > to Peter to decide the best course of action.
> 
> We'll defer to the maintainers of the subsystem as to what they want
> here.  If they say take this smaller patch, we'll be glad to do so.

So if the timing of all this would've been slightly different, I'd have
taken the smaller patch and routed it through sched/urgent in time for
the 6.17 release. And we'd not have had this discussion, but alas.

Also, while we're fairly confident in the task throttling rework, it is
somewhat invasive and hasn't seen widespread testing -- it is
conceivable there are performance issues.

So at this point I would really rather backport the smaller patch that
fixes the immediate bug.

Thanks!