From: Aaron Lu <ziqianlu@bytedance.com>
To: Valentin Schneider <vschneid@redhat.com>
Cc: Ben Segall <bsegall@google.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Peter Zijlstra <peterz@infradead.org>,
Chengming Zhou <chengming.zhou@linux.dev>,
Josh Don <joshdon@google.com>, Ingo Molnar <mingo@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Xi Wang <xii@google.com>,
linux-kernel@vger.kernel.org, Juri Lelli <juri.lelli@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Mel Gorman <mgorman@suse.de>,
Chuyi Zhou <zhouchuyi@bytedance.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Florian Bezdeka <florian.bezdeka@siemens.com>,
Songtang Liu <liusongtang@bytedance.com>
Subject: Re: [PATCH v3 3/5] sched/fair: Switch to task based throttle model
Date: Thu, 28 Aug 2025 11:50:52 +0800 [thread overview]
Message-ID: <20250828035052.GA35@bytedance> (raw)
In-Reply-To: <xhsmhsei2ox4o.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
On Fri, Aug 08, 2025 at 01:45:11PM +0200, Valentin Schneider wrote:
> On 08/08/25 18:13, Aaron Lu wrote:
> > On Fri, Aug 08, 2025 at 11:12:48AM +0200, Valentin Schneider wrote:
... ...
> >> > + if (throttled_hierarchy(cfs_rq) &&
> >> > + !task_current_donor(rq_of(cfs_rq), p)) {
> >> > + list_add(&p->throttle_node, &cfs_rq->throttled_limbo_list);
> >> > + return true;
> >> > + }
> >> > +
> >> > + /* we can't take the fast path, do an actual enqueue*/
> >> > + p->throttled = false;
> >>
> >> So we clear p->throttled but not p->throttle_node? Won't that cause issues
> >> when @p's previous cfs_rq gets unthrottled?
> >>
> >
> > p->throttle_node is already removed from its previous cfs_rq at dequeue
> > time in dequeue_throttled_task().
> >
> > This is done so because in enqueue time, we may not hold its previous
> > rq's lock so can't touch its previous cfs_rq's limbo list, like when
> > dealing with affinity changes.
> >
>
> Ah right, the DQ/EQ_throttled_task() functions are when DQ/EQ is applied to an
> already-throttled task and it does the right thing.
>
> Does this mean we want this as enqueue_throttled_task()'s prologue?
>
> /* @p should have gone through dequeue_throttled_task() first */
> WARN_ON_ONCE(!list_empty(&p->throttle_node));
>
While adding this change to the new version, I remembered this
enqueue_throttled_task() also gets called for tasks that are going to be
unthrottled on unthrottle path, i.e.
unthrottle_cfs_rq() -> tg_unthrottle_up() -> enqueue_task_fair()
because task's throttled flag is not cleared yet(but throttle_node is
removed from the limbo list so the above warn still works as expected).
I didn't clear p->throttled in tg_unthrottle_up() before calling
enqueue_task_fair() because enqueue_throttled_task() will take care of
that but now I look at it, I think it is better to clear p->throttled
before calling enqueue_task_fair(): this saves some cycles by skipping
enqueue_throttled_task() for these unthrottled tasks and
enqueue_throttled_task() only has to deal with migrated throttled task.
This feels cleaner and more efficient. I remember Prateek also suggested
this before but I couldn't find his email now, not sure if I remembered
wrong.
Any way, just a note that I'm going to make below changes to the next
version, let me know if this doesn't look right, thanks.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 785a15caffbcc..df8dc389af8e1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5904,6 +5904,7 @@ static int tg_unthrottle_up(struct task_group *tg, void *data)
/* Re-enqueue the tasks that have been throttled at this level. */
list_for_each_entry_safe(p, tmp, &cfs_rq->throttled_limbo_list, throttle_node) {
list_del_init(&p->throttle_node);
+ p->throttled = false;
enqueue_task_fair(rq_of(cfs_rq), p, ENQUEUE_WAKEUP);
}
next prev parent reply other threads:[~2025-08-28 3:51 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 7:16 [PATCH v3 0/5] Defer throttle when task exits to user Aaron Lu
2025-07-15 7:16 ` [PATCH v3 1/5] sched/fair: Add related data structure for task based throttle Aaron Lu
2025-07-15 7:16 ` [PATCH v3 2/5] sched/fair: Implement throttle task work and related helpers Aaron Lu
2025-07-15 7:16 ` [PATCH v3 3/5] sched/fair: Switch to task based throttle model Aaron Lu
2025-07-15 23:29 ` kernel test robot
2025-07-16 6:57 ` Aaron Lu
2025-07-16 7:40 ` Philip Li
2025-07-16 11:15 ` [PATCH v3 update " Aaron Lu
2025-07-16 11:27 ` [PATCH v3 " Peter Zijlstra
2025-07-16 15:20 ` kernel test robot
2025-07-17 3:52 ` Aaron Lu
2025-07-23 8:21 ` Oliver Sang
2025-07-23 10:08 ` Aaron Lu
2025-08-08 9:12 ` Valentin Schneider
2025-08-08 10:13 ` Aaron Lu
2025-08-08 11:45 ` Valentin Schneider
2025-08-12 8:48 ` Aaron Lu
2025-08-14 15:54 ` Valentin Schneider
2025-08-15 9:30 ` Aaron Lu
2025-08-22 11:07 ` Aaron Lu
2025-09-03 7:14 ` Aaron Lu
2025-09-03 9:11 ` K Prateek Nayak
2025-09-03 10:11 ` Aaron Lu
2025-09-03 10:31 ` K Prateek Nayak
2025-09-03 11:35 ` Aaron Lu
2025-09-04 7:33 ` Bezdeka, Florian
2025-09-04 8:26 ` K Prateek Nayak
2025-09-04 8:40 ` Aaron Lu
2025-08-28 3:50 ` Aaron Lu [this message]
2025-08-17 8:50 ` Chen, Yu C
2025-08-18 2:50 ` Aaron Lu
2025-08-18 3:10 ` Chen, Yu C
2025-08-18 3:12 ` Aaron Lu
2025-07-15 7:16 ` [PATCH v3 4/5] sched/fair: Task based throttle time accounting Aaron Lu
2025-08-18 14:57 ` Valentin Schneider
2025-08-19 9:34 ` Aaron Lu
2025-08-19 14:09 ` Valentin Schneider
2025-08-26 14:10 ` Michal Koutný
2025-08-27 15:16 ` Valentin Schneider
2025-08-28 6:06 ` Aaron Lu
2025-08-26 9:15 ` Aaron Lu
2025-07-15 7:16 ` [PATCH v3 5/5] sched/fair: Get rid of throttled_lb_pair() Aaron Lu
2025-07-15 7:22 ` [PATCH v3 0/5] Defer throttle when task exits to user Aaron Lu
2025-08-01 14:31 ` Matteo Martelli
2025-08-04 7:52 ` Aaron Lu
2025-08-04 11:18 ` Valentin Schneider
2025-08-04 11:56 ` Aaron Lu
2025-08-08 16:37 ` Matteo Martelli
2025-08-04 8:51 ` K Prateek Nayak
2025-08-04 11:48 ` Aaron Lu
2025-08-27 14:58 ` Valentin Schneider
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250828035052.GA35@bytedance \
--to=ziqianlu@bytedance.com \
--cc=bsegall@google.com \
--cc=chengming.zhou@linux.dev \
--cc=dietmar.eggemann@arm.com \
--cc=florian.bezdeka@siemens.com \
--cc=jan.kiszka@siemens.com \
--cc=joshdon@google.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liusongtang@bytedance.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xii@google.com \
--cc=zhouchuyi@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.