From: Tejun Heo <tj@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
David Vernet <void@manifault.com>,
K Prateek Nayak <kprateek.nayak@amd.com>
Subject: [PATCH v2 sched_ext/for-6.12] sched/fair: Make balance_fair() test sched_fair_runnable() instead of rq->nr_running
Date: Mon, 5 Aug 2024 12:39:10 -1000 [thread overview]
Message-ID: <ZrFUjlCf7x3TNXB8@slm.duckdns.org> (raw)
In-Reply-To: <Zq2GJMEl0nG0DMyX@slm.duckdns.org>
balance_fair() skips newidle balancing if rq->nr_running - there are already
tasks on the rq, so no need to try to pull tasks. This tests the total
number of queued tasks on the CPU instead of only the fair class, but is
still correct as the rq can currently only have fair class tasks while
balance_fair() is running.
However, with the addition of sched_ext below the fair class, this will not
hold anymore and make put_prev_task_balance() skip sched_ext's balance()
incorrectly as, when a CPU has only lower priority class tasks,
rq->nr_running would still be positive and balance_fair() would return 1
even when fair doesn't have any tasks to run.
Update balance_fair() to use sched_fair_runnable() which tests
rq->cfs.nr_running which is updated by bandwidth throttling. Note that
pick_next_task_fair() already uses sched_fair_runnable() in its optimized
path for the same purpose.
v2: K Prateek Nayak pointed out that the bw control issue described in v1
was incorrect. Patch description updated. As this makes the patch only
relevant for sched_ext, I'll carry this through the sched_ext tree
unless there are objections.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Peter Zijlstra <peterz@infradead.org>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8323,7 +8323,7 @@ static void set_cpus_allowed_fair(struct
static int
balance_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
{
- if (rq->nr_running)
+ if (sched_fair_runnable(rq))
return 1;
return sched_balance_newidle(rq, rf) != 0;
next prev parent reply other threads:[~2024-08-05 22:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-03 1:21 [PATCH tip/sched/core] " Tejun Heo
2024-08-05 3:21 ` K Prateek Nayak
2024-08-05 18:03 ` Tejun Heo
2024-08-05 22:39 ` Tejun Heo [this message]
2024-08-06 1:37 ` [PATCH v2 sched_ext/for-6.12] " Chengming Zhou
2024-08-06 5:26 ` K Prateek Nayak
2024-08-07 10:51 ` [tip: sched/core] " tip-bot2 for Tejun Heo
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=ZrFUjlCf7x3TNXB8@slm.duckdns.org \
--to=tj@kernel.org \
--cc=kernel-team@meta.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=void@manifault.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®