lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Wed,  6 Apr 2022 19:46:20 +0800
From:   zgpeng <zgpeng.linux@...il.com>
To:     mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
        bristot@...hat.com, linux-kernel@...r.kernel.org
Subject: [PATCH] sched/fair: Simplify the scene where both local and busiest are group_fully_busy

When both local and busiest group are group_fully_busy type, because
the avg_load of the group of type group_fully_busy is not calculated, the
avg_load value is equal to 0. In this case, load balancing will not actually 
done, because after a series of calculations in the calculate_imbalance, it 
will be considered that load balance is not required. Therefore,it is not
necessary to enter calculate_imbalance to do some useless work.

Signed-off-by: zgpeng <zgpeng@...cent.com>
Reviewed-by: Samuel Liao <samuelliao@...cent.com>
---
 kernel/sched/fair.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9f75303..cc1d6c4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -9634,6 +9634,18 @@ static struct sched_group *find_busiest_group(struct lb_env *env)
 			 * busiest doesn't have any tasks waiting to run
 			 */
 			goto out_balanced;
+
+		if (local->group_type == group_fully_busy)
+			/*
+			 * If local group is group_fully_busy, the code goes here,
+			 * the type of busiest group must also be group_fully_busy.
+			 * Because the avg_load of the group_fully_busy type is not
+			 * calculated at present, it is actually equal to 0. In this
+			 * scenario, load balance is not performed. therefore, it can
+			 * be returned directly here, and there is no need to do some
+			 * useless work in calculate_imbalance.
+			 */
+			goto out_balanced;
 	}
 
 force_balance:
-- 
2.9.5

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ