Re: [PATCH 0/2] sched/fair: Use cfs_rq->h_curr in the bandwidth paths
From: Aaron Lu
Date: Mon Aug 31 2026 - 22:43:59 EST
On Mon, Aug 31, 2026 at 06:11:39PM +0800, Wanwu Li wrote:
> Hi Peter, Ingo,
>
> Since commit 85570f10a4c6 ("sched/eevdf: Move to a single runqueue")
> the per-level "is something running at this level" information moved
> from cfs_rq->curr to cfs_rq->h_curr; cfs_rq->curr is now only
> maintained on the root cfs_rq. The cgroup hierarchy is kept for load
> tracking and bandwidth accounting, which makes the bandwidth paths the
> only code that still runs per-level and consults a per-level current.
> Two locations were not updated in this conversion:
>
> 1/2: throttle_cfs_rq() reads cfs_rq->curr to decide whether the
> throttled level has a running entity. For intermediate cfs_rqs
> the check is always false, so quota exhaustion never requests a
> full sched_cfs_bandwidth_slice() and never arms the deferred
> throttle task_work via task_throttle_setup_work(); a running
> task can out-run its group's quota until the next pick armed
> the work instead.
>
> 2/2: distribute_cfs_runtime() gates its clock refresh and runtime
> accounting on cfs_rq->curr, which never fires for cgroup
> cfs_rqs. Since commit 28ad5427682b ("sched/fair: Call
> update_curr() before unthrottling the hierarchy")
> unthrottle_cfs_rq() catches up unconditionally, so this is not
> a correctness hole today, but the refresh the check was written
> for is gone.
For this series:
Reviewed-by: Aaron Lu <ziqianlu@xxxxxxxxxxxxx>
I also run a test where a nop is affined to a single cpu and I can see
that nop task can use more than its quota from time to time; with this
series applied, this no longer happens, so:
Tested-by: Aaron Lu <ziqianlu@xxxxxxxxxxxxx>