From: Aaron Lu <ziqianlu@bytedance.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Valentin Schneider <vschneid@redhat.com>,
Ben Segall <bsegall@google.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
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>,
Chengming Zhou <chengming.zhou@linux.dev>,
Chuyi Zhou <zhouchuyi@bytedance.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Florian Bezdeka <florian.bezdeka@siemens.com>
Subject: Re: [PATCH 2/7] sched/fair: prepare throttle path for task based throttle
Date: Thu, 29 May 2025 19:51:48 +0800 [thread overview]
Message-ID: <20250529115129.GA541982@bytedance> (raw)
In-Reply-To: <20250523073939.GA1038318@bytedance>
On Fri, May 23, 2025 at 03:40:14PM +0800, Aaron Lu wrote:
> On Thu, May 22, 2025 at 01:07:28PM +0200, Peter Zijlstra wrote:
> > On Tue, May 20, 2025 at 06:41:05PM +0800, Aaron Lu wrote:
> > > @@ -8851,6 +8913,7 @@ static struct task_struct *pick_task_fair(struct rq *rq)
> > > {
> > > struct sched_entity *se;
> > > struct cfs_rq *cfs_rq;
> > > + struct task_struct *p;
> > >
> > > again:
> > > cfs_rq = &rq->cfs;
> > > @@ -8871,7 +8934,14 @@ static struct task_struct *pick_task_fair(struct rq *rq)
> > > cfs_rq = group_cfs_rq(se);
> > > } while (cfs_rq);
> > >
> > > - return task_of(se);
> > > + p = task_of(se);
> > > + if (throttled_hierarchy(cfs_rq_of(se))) {
> > > + /* Shuold not happen for now */
> > > + WARN_ON_ONCE(1);
> > > + task_throttle_setup_work(p);
> > > + }
> > > +
> > > + return p;
> > > }
> >
> > So the final code is a little different, because you're removing the
> > return value from check_cfs_rq_runtime().
> >
> > But would not that exact return value be the thing you're now checking
> > for again?
> >
>
> Ah yes.
>
> > That is; at the end of the series, would not something like:
> >
> > static struct task_struct *pick_task_fair(struct rq *rq)
> > {
> > struct sched_entity *se;
> > struct cfs_rq *cfs_rq;
> > struct task_struct *p;
> > bool throttled;
> >
> > again:
> > cfs_rq = &rq->cfs;
> > if (!cfs_rq->nr_queued)
> > return NULL;
> >
> > throttled = false;
> >
> > do {
> > if (cfs_rq->curr && cfs_rq->curr->on_rq)
> > update_curr(cfs_rq);
> >
> > throttled |= check_cfs_rq_runtime(cfs_rq);
> >
> > se = pick_next_entity(rq, cfs_rq);
> > if (!se)
> > goto again;
> >
> > cfs_rq = group_cfs_rq(se);
> > } while (cfs_rq);
> >
> > p = task_of(se);
> > if (unlikely(throttled))
> > task_throttle_setup_work(p);
> > return p;
> > }
> >
> > make it more obvious / be simpler?
>
> Thanks for the suggestion, will follow it in next version.
Found a tiny difference while testing: check_cfs_rq_runtime() could
return false for a cfs_rq whose throttled_hierarchy() is true. The
reason is, that still throttled cfs_rq may be assigned runtime by
another cpu doing distribute_cfs_runtime() and has an async unthrottle
queued but didn't process it yet. The end result is, it has a positive
runtime_remaining but isn't unthrottled yet. I think this doesn't make
much difference but thought it might be worth mentioning.
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()?
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
next prev parent reply other threads:[~2025-05-29 11:51 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 10:41 [PATCH 0/7] Defer throttle when task exits to user Aaron Lu
2025-05-20 10:41 ` [PATCH 1/7] sched/fair: Add related data structure for task based throttle Aaron Lu
2025-05-21 8:48 ` Chengming Zhou
2025-05-20 10:41 ` [PATCH 2/7] sched/fair: prepare throttle path " Aaron Lu
2025-05-20 12:02 ` Florian Bezdeka
2025-05-21 6:37 ` Aaron Lu
2025-05-21 11:51 ` Aaron Lu
2025-05-21 9:01 ` Chengming Zhou
2025-05-21 9:21 ` [External] " Aaron Lu
2025-05-22 11:43 ` Chengming Zhou
2025-05-23 8:03 ` Aaron Lu
2025-05-22 10:48 ` Peter Zijlstra
2025-05-22 11:44 ` Aaron Lu
2025-05-22 11:54 ` Peter Zijlstra
2025-05-22 12:40 ` Aaron Lu
2025-05-23 9:53 ` Aaron Lu
2025-05-23 10:52 ` Peter Zijlstra
2025-05-23 11:17 ` Aaron Lu
2025-05-22 11:07 ` Peter Zijlstra
2025-05-23 7:40 ` Aaron Lu
2025-05-29 11:51 ` Aaron Lu [this message]
2025-05-30 5:36 ` K Prateek Nayak
2025-05-30 11:02 ` Aaron Lu
2025-05-23 12:35 ` Peter Zijlstra
2025-05-20 10:41 ` [PATCH 3/7] sched/fair: prepare unthrottle " Aaron Lu
2025-05-20 10:41 ` [PATCH 4/7] sched/fair: Take care of group/affinity/sched_class change for throttled task Aaron Lu
2025-05-22 12:03 ` Peter Zijlstra
2025-05-22 12:49 ` Aaron Lu
2025-05-23 14:59 ` Peter Zijlstra
2025-05-26 11:36 ` Aaron Lu
2025-05-27 6:58 ` Aaron Lu
2025-05-27 11:19 ` K Prateek Nayak
2025-05-27 11:54 ` Aaron Lu
2025-05-27 14:16 ` K Prateek Nayak
2025-05-23 2:43 ` Chengming Zhou
2025-05-23 7:56 ` Aaron Lu
2025-05-23 9:13 ` Chengming Zhou
2025-05-23 9:42 ` Aaron Lu
2025-05-23 9:53 ` Chengming Zhou
2025-05-23 11:59 ` Aaron Lu
2025-05-26 13:14 ` Chengming Zhou
2025-05-20 10:41 ` [PATCH 5/7] sched/fair: switch to task based throttle model Aaron Lu
2025-05-20 10:41 ` [PATCH 6/7] sched/fair: task based throttle time accounting Aaron Lu
2025-05-20 10:41 ` [PATCH 7/7] sched/fair: get rid of throttled_lb_pair() Aaron Lu
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=20250529115129.GA541982@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=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.