From: Aaron Lu <ziqianlu@bytedance.com>
To: Valentin Schneider <vschneid@redhat.com>,
Ben Segall <bsegall@google.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Peter Zijlstra <peterz@infradead.org>,
Josh Don <joshdon@google.com>, Ingo Molnar <mingo@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Xi Wang <xii@google.com>
Cc: 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>
Subject: Re: [RFC PATCH v2 2/7] sched/fair: Handle throttle path for task based throttle
Date: Wed, 30 Apr 2025 18:01:56 +0800 [thread overview]
Message-ID: <20250430100156.GA322193@bytedance> (raw)
In-Reply-To: <20250409120746.635476-3-ziqianlu@bytedance.com>
On Wed, Apr 09, 2025 at 08:07:41PM +0800, Aaron Lu wrote:
... ...
> @@ -8888,6 +8884,9 @@ pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf
> goto idle;
> se = &p->se;
>
> + if (throttled_hierarchy(cfs_rq_of(se)))
> + task_throttle_setup_work(p);
> +
Looks like this will miss core scheduling case, where the task pick is
done in pick_task_fair().
I plan to do something below on top to fix core scheduling case:
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 70f7de82d1d9d..500b41f9aea72 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8858,6 +8858,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;
@@ -8877,7 +8878,11 @@ 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)))
+ task_throttle_setup_work(p);
+
+ return p;
}
static void __set_next_task_fair(struct rq *rq, struct task_struct *p, bool first);
@@ -8896,9 +8901,6 @@ pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf
goto idle;
se = &p->se;
- if (throttled_hierarchy(cfs_rq_of(se)))
- task_throttle_setup_work(p);
-
#ifdef CONFIG_FAIR_GROUP_SCHED
if (prev->sched_class != &fair_sched_class)
goto simple;
For non-core-scheduling, this has the same effect as current and for
core-scheduling, this will make sure task picked will also get throttle
task work added. It could add throttle task work to a task unnecessarily
because in core scheduling case, a task picked may not be able to run
due to cookie and priority reasons but at least, it will not miss the
throttle work this way.
Alternatively, I can add a task_throttle_setup_work(p) somewhere in
set_next_task_fair() but that would add one more callsite of
throttle_setup_work() and is not as clean and simple as the above diff.
Feel free to let me know your thoughts, thanks!
> #ifdef CONFIG_FAIR_GROUP_SCHED
> if (prev->sched_class != &fair_sched_class)
> goto simple;
next prev parent reply other threads:[~2025-04-30 10:02 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 12:07 [RFC PATCH v2 0/7] Defer throttle when task exits to user Aaron Lu
2025-04-09 12:07 ` [RFC PATCH v2 1/7] sched/fair: Add related data structure for task based throttle Aaron Lu
2025-04-14 3:58 ` K Prateek Nayak
2025-04-14 11:55 ` Aaron Lu
2025-04-14 13:37 ` K Prateek Nayak
2025-04-09 12:07 ` [RFC PATCH v2 2/7] sched/fair: Handle throttle path " Aaron Lu
2025-04-14 8:54 ` Florian Bezdeka
2025-04-14 12:10 ` Aaron Lu
2025-04-14 14:39 ` Florian Bezdeka
2025-04-14 15:02 ` K Prateek Nayak
2025-04-30 10:01 ` Aaron Lu [this message]
2025-04-09 12:07 ` [RFC PATCH v2 3/7] sched/fair: Handle unthrottle " Aaron Lu
2025-04-09 12:07 ` [RFC PATCH v2 4/7] sched/fair: Take care of group/affinity/sched_class change for throttled task Aaron Lu
2025-04-09 12:07 ` [RFC PATCH v2 5/7] sched/fair: get rid of throttled_lb_pair() Aaron Lu
2025-04-09 12:07 ` [RFC PATCH v2 6/7] sched/fair: fix h_nr_runnable accounting with per-task throttle Aaron Lu
2025-04-09 12:07 ` [RFC PATCH v2 7/7] sched/fair: alternative way of accounting throttle time Aaron Lu
2025-04-09 14:24 ` Aaron Lu
2025-04-17 14:06 ` Florian Bezdeka
2025-04-18 3:15 ` Aaron Lu
2025-04-22 15:03 ` Florian Bezdeka
2025-04-23 11:26 ` Aaron Lu
2025-04-23 12:15 ` Florian Bezdeka
2025-04-24 2:26 ` Aaron Lu
2025-05-07 9:09 ` Aaron Lu
2025-05-07 9:33 ` Florian Bezdeka
2025-05-08 2:45 ` Aaron Lu
2025-05-08 6:13 ` Jan Kiszka
2025-05-08 13:43 ` Steven Rostedt
2025-04-14 3:05 ` [RFC PATCH v2 0/7] Defer throttle when task exits to user Chengming Zhou
2025-04-14 11:47 ` Aaron Lu
2025-04-14 8:54 ` Florian Bezdeka
2025-04-14 12:04 ` Aaron Lu
2025-04-15 5:29 ` Jan Kiszka
2025-04-15 6:05 ` K Prateek Nayak
2025-04-15 6:09 ` Jan Kiszka
2025-04-15 8:45 ` K Prateek Nayak
2025-04-15 10:21 ` Jan Kiszka
2025-04-15 11:14 ` K Prateek Nayak
[not found] ` <ec2cea83-07fe-472f-8320-911d215473fd@amd.com>
2025-04-15 15:49 ` K Prateek Nayak
2025-04-22 2:10 ` Aaron Lu
2025-04-22 2:54 ` K Prateek Nayak
2025-04-22 14:54 ` Florian Bezdeka
2025-04-15 10:34 ` K Prateek Nayak
2025-04-14 16:34 ` K Prateek Nayak
2025-04-15 11:25 ` 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=20250430100156.GA322193@bytedance \
--to=ziqianlu@bytedance.com \
--cc=bsegall@google.com \
--cc=chengming.zhou@linux.dev \
--cc=dietmar.eggemann@arm.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.