[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250701024549.40166-1-adamli@os.amperecomputing.com>
Date: Tue, 1 Jul 2025 02:45:47 +0000
From: Adam Li <adamli@...amperecomputing.com>
To: mingo@...hat.com,
peterz@...radead.org,
juri.lelli@...hat.com,
vincent.guittot@...aro.org
Cc: dietmar.eggemann@....com,
rostedt@...dmis.org,
bsegall@...gle.com,
mgorman@...e.de,
vschneid@...hat.com,
cl@...ux.com,
linux-kernel@...r.kernel.org,
patches@...erecomputing.com,
Adam Li <adamli@...amperecomputing.com>
Subject: [PATCH 0/2] Fix imbalance issue when balancing fork
Load imbalance is observed when the workload frequently forks new threads.
Due to CPU affinity, the workload can run on CPU 0-7 in the first
group, and only on CPU 8-11 in the second group. CPU 12-15 are always idle.
{ 0 1 2 3 4 5 6 7 } {8 9 10 11 12 13 14 15}
* * * * * * * * * * * *
When looking for dst group for newly forked threads, in many times
update_sg_wakeup_stats() reports the second group has more idle CPUs
than the first group. The scheduler thinks the second group is less
busy. Then it selects least busy CPUs among CPU 8-11. So CPU 8-11 can be
crowded with newly forked threads, at the same time CPU 0-7 can be idle.
The first patch 'Only update stats of allowed CPUs when looking for dst
group' *alone* can fix this imbalance issue.
And I think the second patch also makes sense in this scenario. If group
weight includes CPUs a task cannot use, group classification can be
incorrect. Please comment.
Adam Li (2):
sched/fair: Only update stats of allowed CPUs when looking for dst
group
sched/fair: Only count group weight for allowed CPUs when looking for
dst group
kernel/sched/fair.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--
2.34.1
Powered by blists - more mailing lists