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

[Phil Auld <pauld@redhat.com>]

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?


Also, I can't find this commit in tip. It's visible in gitweb but it's not
in the tip tree as far as I can tell. 


> v4.9.167: Failed to apply! Possible dependencies:
>     8a8c69c32778 ("sched/core: Add rq->lock wrappers")
>     92509b732baf ("sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock")
>     c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
>     cb42c9a3ebbb ("sched/core: Add debugging code to catch missing update_rq_clock() calls")
>     d1ccc66df8bf ("sched/core: Clean up comments")
>     d8ac897137a2 ("sched/core: Add wrappers for lockdep_(un)pin_lock()")
> 
> v4.4.178: Failed to apply! Possible dependencies:
>     2a67e741bbbc ("rcu: Create transitive rnp->lock acquisition functions")
>     3e71a462dd48 ("sched/core: Move task_rq_lock() out of line")
>     3ea94de15ce9 ("sched/core: Fix incorrect wait time and wait count statistics")
>     46a5d164db53 ("rcu: Stop disabling interrupts in scheduler fastpaths")
>     8a8c69c32778 ("sched/core: Add rq->lock wrappers")
>     958c5f848e17 ("stop_machine: Change stop_one_cpu() to rely on cpu_stop_queue_work()")
>     bf89a304722f ("stop_machine: Avoid a sleep and wakeup in stop_one_cpu()")
>     c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
>     cb2517653fcc ("sched/debug: Make schedstats a runtime tunable that is disabled by default")
>     d8ac897137a2 ("sched/core: Add wrappers for lockdep_(un)pin_lock()")
>     e7904a28f533 ("locking/lockdep, sched/core: Implement a better lock pinning scheme")
>     fecbf6f01fbd ("rcu: Simplify rcu_sched_qs() control flow")
> 
> v3.18.138: Failed to apply! Possible dependencies:
>     1a43a14a5bd9 ("sched: Fix schedule_tail() to disable preemption")
>     1b537c7d1e58 ("sched/core: Remove check of p->sched_class")
>     1d7e974cbf2f ("sched/deadline: Don't check SD_BALANCE_FORK")
>     3960c8c0c789 ("sched: Make dl_task_time() use task_rq_lock()")
>     3e71a462dd48 ("sched/core: Move task_rq_lock() out of line")
>     4c9a4bc89a9c ("sched: Allow balance callbacks for check_class_changed()")
>     5cc389bcee08 ("sched: Move code around")
>     5e16bbc2fb40 ("sched: Streamline the task migration locking a little")
>     67dfa1b756f2 ("sched/deadline: Implement cancel_dl_timer() to use in switched_from_dl()")
>     6c1d9410f007 ("sched: Move p->nr_cpus_allowed check to select_task_rq()")
>     74b8a4cb6ce3 ("sched: Clarify ordering between task_rq_lock() and move_queued_task()")
>     8a8c69c32778 ("sched/core: Add rq->lock wrappers")
>     c0ad4aa4d841 ("sched/fair: Robustify CFS-bandwidth timer locking")
>     cbce1a686700 ("sched,lockdep: Employ lock pinning")
>     dfa50b605c2a ("sched: Make finish_task_switch() return 'struct rq *'")
>     f4e9d94a5bf6 ("sched/deadline: Don't balance during wakeup if wakee is pinned")
> 
> 
> How should we proceed with this patch?
>

I haven't look that far back.  This patch should be pretty self contained. I don't
think it's worth pulling it back to these trees if it would require all of these
patches.  The risk would out-weigh the reward.


Cheers,
Phil


> --
> Thanks,
> Sasha

--