Re: [PATCH 5/5] sched/fair: Unify cfs_rq throttling via account_cfs_rq_runtime()

[Benjamin Segall <bsegall@google.com>]

K Prateek Nayak <kprateek.nayak@amd.com> writes:

> From: Peter Zijlstra <peterz@infradead.org>
>
> assign_cfs_rq_runtime() during update_curr() sets the resched indicator
> and relies on check_cfs_rq_runtime() during pick_next_task() /
> put_prev_entity() to throttle the hierarchy once current task is
> preempted / blocks.
>
> Per-task throttle, on the other hand, uses throttle_cfs_rq() to simply
> propagate the throttle signals, and then relies on task work to
> individually throttle the runnable tasks on their way out to the
> userspace.
>
> Remove check_cfs_rq_runtime() and unify throttling into
> account_cfs_rq_runtime() which only sets the cfs_rq->throttled,
> cfs_rq->throttle_count indicators via throttle_cfs_rq() and optionally
> adds the task work to the current task (donor) it is on the throttled
> hierarchy.
>
> throttle_cfs_rq() requests for sched_cfs_bandwidth_slice() worth of
> bandwidth for the current hierarchy that enable it to continue running
> uninterrupted when selected. For the rest, it requests a bare minimum of
> "1" to ensure some bandwidth is available and pass the
> "runtime_remaining > 0" checks once selected.
>
> For SCHED_PROXY_EXEC, a mutex holder cannot exit to userspace without
> dropping it first and the mutex_unlock() ensures proxy is stopped before
> the mutex handoff which preserves the current semantics for running a
> throttled task until it exits to the userspace even if it acts as a
> donor.
>
>   [ prateek: rebased on tip, comments, commit message. ]

Yeah, no need to go into schedule() anymore. Having some extra callers
of task_throttle_setup_work() instead is better.

Reviewed-By: Benjamin Segall <bsegall@google.com>