Re: [PATCH] sched/fair: Prevent cfs_rq from being unthrottled with zero runtime_remaining

[Aaron Lu <ziqianlu@bytedance.com>]

On Thu, Oct 16, 2025 at 07:04:30PM +0800, Hao Jia wrote:
> On 2025/10/16 17:23, Aaron Lu wrote:
... ...
> > With the above said, this shouldn't matter anymore but just out of
> > curiosity: did you notice this by inspecting the code or actually
> > hitting the warning about using an outdated rq clock?
> > 
> > Per my understanding, most likely: __assign_cfs_rq_runtime() in
> > throttle_cfs_rq(cfs_rq) will grant 1ns runtime to cfs_rq so it won't
> > reach tg_throttle_down(). The comment I added above that if condition
> > is kind of misleading though.
> 
> 
> I did encounter this once.
> 
> perhaps in the following corner case:
> 
> If cfs_b->quota is set low (and quota is set at each level), and there are a
> large number of CPUs.
> 
> After tg_set_cfs_bandwidth()->__refill_cfs_bandwidth_runtime(), we release
> cfs_b->lock. cfs_b->runtime might be consumed by cfs_rq on other CPUs.

Ah I see. So I suppose in your setup, tasks are already started and then
quota is set.

> 
> Then, on one online CPU, we can't get 1ns runtime via
> __assign_cfs_rq_runtime(). Current limiting is triggered on this CPU, and
> tg_throttle_down()->rq_clock_pelt() is called.
> 

Got it, thanks for the info!