From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Xin Zhao <jackzxcui1989@163.com>
Cc: <bsegall@google.com>, <dietmar.eggemann@arm.com>,
<juri.lelli@redhat.com>, <linux-kernel@vger.kernel.org>,
<mgorman@suse.de>, <mingo@redhat.com>, <peterz@infradead.org>,
<rostedt@goodmis.org>, <vincent.guittot@linaro.org>,
<vschneid@redhat.com>
Subject: Re: [RFC PATCH RESEND 01/10] sched/fair: Do not set_rd_overloaded() if rd->online != env->cpus
Date: Fri, 11 Sep 2026 11:51:10 +0530 [thread overview]
Message-ID: <b44631c1-4272-4860-88f7-14c62de5e2fd@amd.com> (raw)
In-Reply-To: <20260911010623.2425196-1-jackzxcui1989@163.com>
Hello Xin,
On 9/11/2026 6:36 AM, Xin Zhao wrote:
> On Thu, 10 Sep 2026 14:00:43 +0530 K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>
>> Only two cases manipulate env.cpus:
>>
>> 1. LBF_DST_PINNED: The CPU doing the load balancing clears itself from
>> env.cpus since pinned tasks cannot be moved to it and goes to
>> "more_balance" but "more_balance" does not recompute stats and never
>> reaches update_sd_lb_stats().
>>
>> 2. LBF_ALL_PINNED: CPU with no movable task is cleared from env.cpus.
>> How will rd->overload being set for a CPU that cannot be helped make
>> newidle balance any more efficient?
>
> The effective range of LBF_ALL_PINNED is specific to a particular src CPU
> and a particular dst CPU, whereas rd->overload is indeed a global marker
> that affects all CPUs with idle states. Regardless of whether case 1 has
> been processed, it seems unreasonable to me that rd->overload could be
> incorrectly cleared due to case 2, because the scopes of the LBF_ALL_PINNED
> and ->overload flags are not equivalent.
What is the point of doing load balancing if the CPUs that are overloaded
have all their tasks pinned? Those are just wasted cycles.
>> Since LBF_ALL_PINNED is known with busiest's rq_lock held, maybe you
>> can set a rq->flag and later consume it in add_nr_running() to
>> do set_rd_overloaded() selectively.
>
> If the global rd->overload is incorrectly cleared due to LBF_ALL_PINNED
> from src (CPUA) to dst (CPUB), it is possible that CPUB may experience
> no changes in nr_running for a certain period of time.
Why? Tasks can still wake up on it no?
All that clearing rq->overloaded does is indicate to newidle balance
that there aren't any CPUs with movable tasks on them and it is futile
to do any load balancing.
Do you have any numbers where Patch 1 specifically improves stuff?
> Therefore, I think
> modifying it in add_nr_running may not be appropriate. I'm not sure if my
> understanding is correct.
I was thinking something along the lines of:
(Only build tested)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5de115f67065..e78bbdab637f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3000,6 +3000,15 @@ static int affine_move_task(struct rq *rq, struct task_struct *p, struct rq_flag
complete = true;
}
+ /*
+ * At least one task on this rq might be movable again.
+ * Check if rq->overloaded needs to be changed.
+ */
+ if (rq->all_pinned && rq->nr_running > 1) {
+ set_rd_overloaded(rq->rd, 1);
+ rq->all_pinned = 0;
+ }
+
preempt_disable();
task_rq_unlock(rq, p, rf);
if (push_task) {
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 66e3b5cd5902..563327eb5ae8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -13614,6 +13614,19 @@ static int sched_balance_rq(int this_cpu, struct rq *this_rq,
*/
cur_ld_moved = detach_tasks(&env);
+ /*
+ * Indicate this rq currently has all its tasks pinned.
+ * Next enqueue will reset rd->overloaded accordingly
+ * if it was cleared during load balancing.
+ *
+ * XXX: Do this only when update_sd_lb_stats() clears
+ * sd_overloaded? Can this be used to skip CPUs with
+ * pinned tasks in sched_balance_find_src_rq()?
+ */
+ if (!sd_parent &&
+ ((env.flags & (LBF_DST_PINNED | LBF_ALL_PINNED)) == LBF_ALL_PINNED))
+ busiest->all_pinned = 1;
+
/*
* We've detached some tasks from busiest_rq. Every
* task is masked "TASK_ON_RQ_MIGRATING", so we can safely
@@ -13751,6 +13764,7 @@ static int sched_balance_rq(int this_cpu, struct rq *this_rq,
/* Record that we found at least one task that could run on this_cpu */
env.flags &= ~LBF_ALL_PINNED;
+ busiest->all_pinned = 0;
/*
* ->active_balance synchronizes accesses to
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 5950391b873d..651a6e637e37 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1361,6 +1361,9 @@ struct rq {
struct cpuidle_state *idle_state;
#endif
+ unsigned char all_pinned;
+ /* hole */
+
unsigned int nr_pinned;
unsigned int push_busy;
struct cpu_stop_work push_work;
@@ -3060,8 +3063,10 @@ static inline void add_nr_running(struct rq *rq, unsigned count)
call_trace_sched_update_nr_running(rq, count);
}
- if (prev_nr < 2 && rq->nr_running >= 2)
+ if ((prev_nr < 2 || rq->all_pinned) && rq->nr_running >= 2) {
set_rd_overloaded(rq->rd, 1);
+ rq->all_pinned = 0;
+ }
sched_update_tick_dependency(rq);
}
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2026-09-11 6:21 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 4:29 [RFC PATCH RESEND 00/10] sched/fair: A series of load balance patches to improve real-time performance of CFS tasks Xin Zhao
2026-09-10 4:29 ` [RFC PATCH RESEND 01/10] sched/fair: Do not set_rd_overloaded() if rd->online != env->cpus Xin Zhao
2026-09-10 8:30 ` K Prateek Nayak
2026-09-10 13:45 ` Vincent Guittot
2026-09-11 1:06 ` Xin Zhao
2026-09-11 6:21 ` K Prateek Nayak [this message]
2026-09-12 1:46 ` Xin Zhao
2026-09-12 1:53 ` Xin Zhao
2026-09-10 4:29 ` [RFC PATCH RESEND 02/10] scbed/fair: Remove duplicate check for busiest_cpu in active_load_balance_cpu_stop() Xin Zhao
2026-09-10 11:41 ` Kayra Cizmeci
2026-09-11 0:22 ` Xin Zhao
2026-09-11 9:20 ` Kayra Cizmeci
2026-09-10 4:29 ` [RFC PATCH RESEND 03/10] sched/fair: Clear active_balance at the end of active_load_balance_cpu_stop() Xin Zhao
2026-09-10 8:09 ` K Prateek Nayak
2026-09-10 14:15 ` Xin Zhao
2026-09-10 4:29 ` [RFC PATCH RESEND 04/10] sched/fair: Add LB_PROMOTE feature to enhance real-time performance of fair tasks Xin Zhao
2026-09-11 12:32 ` Vincent Guittot
2026-09-12 4:28 ` Xin Zhao
2026-09-10 4:29 ` [RFC PATCH RESEND 05/10] sched/fair: Introduce select_task_rq_fair_thin() to select rq when LB_PROMOTE Xin Zhao
2026-09-10 8:19 ` Vincent Guittot
2026-09-10 14:39 ` Xin Zhao
2026-09-10 15:31 ` Vincent Guittot
2026-09-10 15:56 ` Xin Zhao
2026-09-11 12:27 ` Vincent Guittot
2026-09-12 4:08 ` Xin Zhao
2026-09-15 11:56 ` Vincent Guittot
2026-09-15 21:43 ` Kayra Cizmeci
2026-09-10 12:00 ` Kayra Cizmeci
2026-09-10 14:56 ` Xin Zhao
2026-09-15 18:19 ` Kayra Cizmeci
2026-09-10 4:29 ` [RFC PATCH RESEND 06/10] sched/fair: Modify active_load_balance_cpu_stop() to accommodate more scenarios Xin Zhao
2026-09-10 4:29 ` [RFC PATCH RESEND 07/10] sched/fair: Trigger active balance if a CFS task is preempted when LB_PROMOTE Xin Zhao
2026-09-10 4:29 ` [RFC PATCH RESEND 08/10] sched/fair: Do not check avg_idle to prematurely exit newly idle " Xin Zhao
2026-09-10 4:29 ` [RFC PATCH RESEND 09/10] sched/fair: Not goto more_balance if newly idle and has pending task when LBF_NEED_BREAK Xin Zhao
2026-09-10 4:29 ` [RFC PATCH RESEND 10/10] sched/fair: Strive to find a task to migrate if newly idle when LB_PROMOTE Xin Zhao
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=b44631c1-4272-4860-88f7-14c62de5e2fd@amd.com \
--to=kprateek.nayak@amd.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=jackzxcui1989@163.com \
--cc=juri.lelli@redhat.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 \
/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®