Re: [tip:sched/core] sched/fair: Limit sched_cfs_period_timer loop to avoid hard lockup

[Phil Auld <pauld@redhat.com>]

On Mon, Apr 08, 2019 at 10:50:26AM -0400 Sasha Levin wrote:
> On Mon, Apr 08, 2019 at 09:42:14AM -0400, Phil Auld wrote:
> > On Fri, Apr 05, 2019 at 02:15:23PM +0000 Sasha Levin wrote:
> > > Hi,
> > > 
> > > [This is an automated email]
> > > 
> > > This commit has been processed because it contains a -stable tag.
> > > The stable tag indicates that it's relevant for the following trees: all
> > > 
> > > The bot has tested the following trees: v5.0.6, v4.19.33, v4.14.110, v4.9.167, v4.4.178, v3.18.138.
> > > 
> > > v5.0.6: Failed to apply! Possible dependencies:
> > >     c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
> > > 
> > > v4.19.33: Failed to apply! Possible dependencies:
> > >     c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
> > > 
> > > v4.14.110: Failed to apply! Possible dependencies:
> > >     c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
> > > 
> > 
> > This is a minor context difference. There is no actual dependency on the
> > c0ad4aa4d841 patch.  It would be easy to produce new version that could
> > go in these trees. I'm not sure what the right action is in that case.
> > Should I spin a new version with the different locking in the context?
> 
> Please do :)
>

Sure. I'm just not sure how to post it. It only shows up in this tip-bot
email and on gitweb. It's not in tip.git and not in Linus' upstream tree.

I've updated the patch at it will apply now to v5.0.6, v4.19.33, v4.14.110,
v4.9.167, v4.4.178  all with increasing offsets but nothing else.

v3.18.138 won't take it without more work. I'd be inclined to skip that one.


> The algorithm does the dependency analysis by looking at surrounding
> code rather than actual functional dependency.


That's pretty cool though :)

Cheers,
Phil


>
> --
> Thanks,
> Sasha

--