forked from clearlinux-pkgs/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsched-hybrid4.patch
136 lines (128 loc) · 5.54 KB
/
sched-hybrid4.patch
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <[email protected]>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
by smtp.lore.kernel.org (Postfix) with ESMTP id 51967ECAAA2
for <[email protected]>; Thu, 25 Aug 2022 22:50:04 +0000 (UTC)
Received: ([email protected]) by vger.kernel.org via listexpand
id S244049AbiHYWuB (ORCPT <rfc822;[email protected]>);
Thu, 25 Aug 2022 18:50:01 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38574 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S243969AbiHYWtp (ORCPT
<rfc822;[email protected]>);
Thu, 25 Aug 2022 18:49:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=intel.com; [email protected]; q=dns/txt; s=Intel;
t=1661467783; x=1693003783;
h=from:to:cc:subject:date:message-id:in-reply-to:
references;
bh=N6JNWD5Gq4S10yyOmOpUW93oRz6lIATWq7O62bXOoYk=;
b=W7U14IdU5J1UjDOKjGcZrX6UvRHN8Ln5hih3YXbAWtWhew7QH9gjt8TJ
iClJa8KQpj//dEv115GOkCObZJpejppMChKY6HVcARMCaAXbiOsWp4+KB
/CIfZbKLZ8oKvcoPSZ9HT0dmKrzLGsdhexbYs5xE5WqVgHCibp+X09rtw
f+OWgQyXv1ZGdbXqXSk2okzrcEfdZvipg+JTjQZcjl/8Zj4i/2fKCmG/f
OEJeHar0diK4HDYynDiecCgLlXiyPpyvhh9yI5wskoyO0BB+91pQzJXf9
Al/z+ZIAx0q+HBz4xXSYe7x1CWnSmfP15qzEgWqMGcuOI8cku5LscKUql
Q==;
X-IronPort-AV: E=McAfee;i="6500,9779,10450"; a="295153925"
X-IronPort-AV: E=Sophos;i="5.93,264,1654585200";
d="scan'208";a="295153925"
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.93,264,1654585200";
d="scan'208";a="678642685"
From: Ricardo Neri <[email protected]>
To: "Peter Zijlstra (Intel)" <[email protected]>,
Juri Lelli <[email protected]>,
Vincent Guittot <[email protected]>
Cc: Ricardo Neri <[email protected]>,
"Ravi V. Shankar" <[email protected]>,
Ben Segall <[email protected]>,
Daniel Bristot de Oliveira <[email protected]>,
Dietmar Eggemann <[email protected]>,
Len Brown <[email protected]>, Mel Gorman <[email protected]>,
"Rafael J. Wysocki" <[email protected]>,
Srinivas Pandruvada <[email protected]>,
Steven Rostedt <[email protected]>,
Tim Chen <[email protected]>,
Valentin Schneider <[email protected]>, [email protected],
Ricardo Neri <[email protected]>,
"Tim C . Chen" <[email protected]>
Subject: [PATCH 4/4] x86/sched: Avoid unnecessary migrations within SMT domains
Date: Thu, 25 Aug 2022 15:55:29 -0700
Message-Id: <[email protected]>
X-Mailer: git-send-email 2.17.1
In-Reply-To: <[email protected]>
References: <[email protected]>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: [email protected]
Having different priorities for each SMT sibling triggers unnecessary
load balancing towards the higher-priority sibling.
The scheduler now has logic to allow lower-priority CPUs to relieve load
from scheduling groups composed of SMT siblings with more than one busy
sibling.
Hence, it is no longer necessary to give different priorities to each of
the SMT siblings of a physical core.
Cc: Ben Segall <[email protected]>
Cc: Daniel Bristot de Oliveira <[email protected]>
Cc: Dietmar Eggemann <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Srinivas Pandruvada <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Tim C. Chen <[email protected]>
Cc: Valentin Schneider <[email protected]>
Reviewed-by: Len Brown <[email protected]>
Signed-off-by: Ricardo Neri <[email protected]>
---
arch/x86/kernel/itmt.c | 23 +++++------------------
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/itmt.c b/arch/x86/kernel/itmt.c
index 9ff480e94511..6510883c5e81 100644
--- a/arch/x86/kernel/itmt.c
+++ b/arch/x86/kernel/itmt.c
@@ -174,32 +174,19 @@ int arch_asym_cpu_priority(int cpu)
/**
* sched_set_itmt_core_prio() - Set CPU priority based on ITMT
- * @prio: Priority of cpu core
- * @core_cpu: The cpu number associated with the core
+ * @prio: Priority of @cpu
+ * @cpu: The CPU number
*
* The pstate driver will find out the max boost frequency
* and call this function to set a priority proportional
- * to the max boost frequency. CPU with higher boost
+ * to the max boost frequency. CPUs with higher boost
* frequency will receive higher priority.
*
* No need to rebuild sched domain after updating
* the CPU priorities. The sched domains have no
* dependency on CPU priorities.
*/
-void sched_set_itmt_core_prio(int prio, int core_cpu)
+void sched_set_itmt_core_prio(int prio, int cpu)
{
- int cpu, i = 1;
-
- for_each_cpu(cpu, topology_sibling_cpumask(core_cpu)) {
- int smt_prio;
-
- /*
- * Ensure that the siblings are moved to the end
- * of the priority chain and only used when
- * all other high priority cpus are out of capacity.
- */
- smt_prio = prio * smp_num_siblings / (i * i);
- per_cpu(sched_core_priority, cpu) = smt_prio;
- i++;
- }
+ per_cpu(sched_core_priority, cpu) = prio * 64 - cpu;
}
--
2.25.1