Re: [PATCH 2/7] sched/fair: prepare throttle path for task based throttle

[Aaron Lu <ziqianlu@bytedance.com>]

Hi Prateek,

On Fri, May 30, 2025 at 11:06:52AM +0530, K Prateek Nayak wrote:
> Hello Aaron,
> 
> On 5/29/2025 5:21 PM, Aaron Lu wrote:
> > A side note, now that check_cfs_rq_runtime() only marks cfs_rq's
> > throttle status and returns a signal, it no longer does dequeuing
> > stuffs, I suppose there is no need to call it in put_prev_entity()?
> 
> But perhaps it is needed to queue the bandwidth timer via
> __assign_cfs_rq_runtime() if the cfs_rq had built up slack when the last
> task was dequeued?
> 
> Otherwise, the throttle will only be noted at the time of pick and the
> timer will only start then but check_cfs_rq_runtime() in
> put_prev_entity() and check_enqueue_throttle() could have already
> spotted a slack and queued the timer which can ensure bandwidth is
> available sooner and reduce latency.
> 
> Let me know if I'm terribly mistaken :)
> 

Sounds reasonable to me, thanks for the insight!

Best wishes,
Aaron

> > Because that signal is now only useful in pick time and we always run
> > check_cfs_rq_runtime() on every cfs_rq encountered during pick.> Also,
> > check_enqueue_throttle() doesn't look useful either because
> > enqueued task will go through pick and we will add a throttle work to it
> > if needed. I removed these stuffs and run some tests, didn't notice
> > anything wrong yet but perhaps I missed something, comments?
> > 
> > Best regards,
> > Aaron
> 
> -- 
> Thanks and Regards,
> Prateek
>