[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <171162285612.10875.3210405155539598767.tip-bot2@tip-bot2>
Date: Thu, 28 Mar 2024 10:47:36 -0000
From: "tip-bot2 for Shrikanth Hegde" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: Shrikanth Hegde <sshegde@...ux.ibm.com>, Ingo Molnar <mingo@...nel.org>,
Qais Yousef <qyousef@...alina.io>,
Vincent Guittot <vincent.guittot@...aro.org>, Mel Gorman <mgorman@...e.de>,
x86@...nel.org, linux-kernel@...r.kernel.org
Subject:
[tip: sched/core] sched/fair: Check root_domain::overload value before update
The following commit has been merged into the sched/core branch of tip:
Commit-ID: c628db0a6831f80e89873ee44f1b40e3ab3216c6
Gitweb: https://git.kernel.org/tip/c628db0a6831f80e89873ee44f1b40e3ab3216c6
Author: Shrikanth Hegde <sshegde@...ux.ibm.com>
AuthorDate: Mon, 25 Mar 2024 11:15:04 +05:30
Committer: Ingo Molnar <mingo@...nel.org>
CommitterDate: Thu, 28 Mar 2024 11:30:13 +01:00
sched/fair: Check root_domain::overload value before update
The root_domain::overload flag is 1 when there's any rq
in the root domain that has 2 or more running tasks. (Ie. it's overloaded.)
The root_domain structure itself is a global structure per cpuset island.
The ::overload flag is maintained the following way:
- Set when adding a second task to the runqueue.
- It is cleared in update_sd_lb_stats() during load balance,
if none of the rqs have 2 or more running tasks.
This flag is used during newidle balance to see if its worth doing a full
load balance pass, which can be an expensive operation. If it is set,
then newidle balance will try to aggressively pull a task.
Since commit:
630246a06ae2 ("sched/fair: Clean-up update_sg_lb_stats parameters")
::overload is being written unconditionally, even if it has the same
value. The change in value of this depends on the workload, but on
typical workloads, it doesn't change all that often: a system is
either dominantly overloaded for substantial amounts of time, or not.
Extra writes to this semi-global structure cause unnecessary overhead, extra
bus traffic, etc. - so avoid it as much as possible.
Perf probe stats show that it's worth making this change (numbers are
with patch applied):
1M probe:sched_balance_newidle_L38
139 probe:update_sd_lb_stats_L53 <====== 1->0 writes
129K probe:add_nr_running_L12
74 probe:add_nr_running_L13 <====== 0->1 writes
54K probe:update_sd_lb_stats_L50 <====== reads
These numbers prove that actual change in the ::overload value is (much) less
frequent: L50 is much larger at ~54,000 accesses vs L53+L13 of 139+74.
[ mingo: Rewrote the changelog. ]
Signed-off-by: Shrikanth Hegde <sshegde@...ux.ibm.com>
Signed-off-by: Ingo Molnar <mingo@...nel.org>
Reviewed-by: Qais Yousef <qyousef@...alina.io>
Reviewed-by: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Mel Gorman <mgorman@...e.de>
Link: https://lore.kernel.org/r/20240325054505.201995-2-sshegde@linux.ibm.com
---
kernel/sched/fair.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3846230..600fdde 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -10657,7 +10657,8 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd
if (!env->sd->parent) {
/* update overload indicator if we are at root domain */
- WRITE_ONCE(env->dst_rq->rd->overload, sg_status & SG_OVERLOAD);
+ if (READ_ONCE(env->dst_rq->rd->overload) != (sg_status & SG_OVERLOAD))
+ WRITE_ONCE(env->dst_rq->rd->overload, sg_status & SG_OVERLOAD);
/* Update over-utilization (tipping point, U >= 0) indicator */
set_rd_overutilized_status(env->dst_rq->rd,
Powered by blists - more mailing lists