[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251028063917.GD33@bytedance>
Date: Tue, 28 Oct 2025 14:39:18 +0800
From: Aaron Lu <ziqianlu@...edance.com>
To: K Prateek Nayak <kprateek.nayak@....com>
Cc: Hao Jia <jiahao.kernel@...il.com>, mingo@...hat.com,
peterz@...radead.org, mingo@...nel.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
vschneid@...hat.com, linux-kernel@...r.kernel.org,
Hao Jia <jiahao1@...iang.com>
Subject: Re: [PATCH v2] sched/fair: Fix non-empty throttled_limbo_list
warning in tg_throttle_down()
On Tue, Oct 28, 2025 at 08:33:15AM +0530, K Prateek Nayak wrote:
> Hello Aaron,
>
> On 10/27/2025 5:32 PM, Aaron Lu wrote:
> > On Mon, Oct 27, 2025 at 05:05:34PM +0800, Hao Jia wrote:
> >> @@ -6403,7 +6407,7 @@ static void do_sched_cfs_slack_timer(struct cfs_bandwidth *cfs_b)
> >> * expired/exceeded, otherwise it may be allowed to steal additional ticks of
> >> * runtime as update_curr() throttling can not trigger until it's on-rq.
> >> */
> >> -static void check_enqueue_throttle(struct cfs_rq *cfs_rq)
> >> +static void check_enqueue_throttle(struct cfs_rq *cfs_rq, int flags)
> >> {
> >> if (!cfs_bandwidth_used())
> >> return;
> >> @@ -6418,6 +6422,13 @@ static void check_enqueue_throttle(struct cfs_rq *cfs_rq)
> >>
> >> /* update runtime allocation */
> >> account_cfs_rq_runtime(cfs_rq, 0);
> >> + /*
> >> + * Do not attempt to throttle on the cfs_rq unthrottle path.
> >> + * and it must be placed after account_cfs_rq_runtime() to
> >> + * prevent a possible missed start of the bandwidth timer.
> >
> > Hi Prateek and Hao,
> >
> > Does it matter to start the bw timer? If no cfs_rq gets throttled, the
> > timer doesn't look that useful.
>
> Ack! But if we've reached here with ENQUEUE_THROTTLE set, we are in fact
> trying to enqueue a task during unthrottling and we only start the timer
> if we don't have any bandwidth since __account_cfs_rq_runtime() would bail
> out if "cfs_rq->runtime_remaining > 0"
> > Also, account_cfs_rq_runtime() calls
> > assign_cfs_rq_runtime() and if assign failed, it will do resched_curr()
> > but since we do not throttle cfs_rq here, that resched would be useless.
>
> resched only happens if "cfs_rq->curr" is set andcheck_enqueue_throttle() already bails out if "cfs_rq->curr" is set so
> the resched is avoided.
Right, sorry I missed that.
Powered by blists - more mailing lists