-
Notifications
You must be signed in to change notification settings - Fork 60
/
0002-sched-migrate.patch
316 lines (270 loc) · 12 KB
/
0002-sched-migrate.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
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
Subject: [PATCH v5 2/2] sched/fair: Introduce SIS_SHORT to wake up short task on current CPU
Date: Fri, 3 Feb 2023 13:18:13 +0800
Message-Id: <1b8af8d99da99a20449288ab4fbba64dc05057ce.1675361144.git.yu.c.chen@intel.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: [email protected]
[Problem Statement]
For a workload that is doing frequent context switches, the throughput
scales well until the number of instances reaches a peak point. After
that peak point, the throughput drops significantly if the number of
instances continues to increase.
The will-it-scale context_switch1 test case exposes the issue. The
test platform has 112 CPUs per LLC domain. The will-it-scale launches
1, 8, 16 ... 112 instances respectively. Each instance is composed
of 2 tasks, and each pair of tasks would do ping-pong scheduling via
pipe_read() and pipe_write(). No task is bound to any CPU.
It is found that, once the number of instances is higher than
56(112 tasks in total, every CPU has 1 task), the throughput
drops accordingly if the instance number continues to increase:
^
throughput|
| X
| X X X
| X X X
| X X
| X X
| X
| X
| X
| X
|
+-----------------.------------------->
56
number of instances
[Symptom analysis]
The performance downgrading was caused by a high system idle
percentage(around 20% ~ 30%). The CPUs waste a lot of time in
idle and do nothing. As a comparison, if set CPU affinity to
these workloads and stops them from migrating among CPUs,
the idle percentage drops to nearly 0%, and the throughput
increases a lot. This indicates room for optimization.
The cause is the race condition between select_task_rq() and
the task enqueue.
Suppose there are nr_cpus pairs of ping-pong scheduling
tasks. For example, p0' and p0 are ping-pong scheduling,
so do p1' <=> p1, and p2'<=> p2. None of these tasks are
bound to any CPUs. The problem can be summarized as:
more than 1 wakers are stacked on 1 CPU, which slows down
waking up their wakees:
CPU0 CPU1 CPU2
p0' p1' => idle p2'
try_to_wake_up(p0) try_to_wake_up(p2);
CPU1 = select_task_rq(p0); CPU1 = select_task_rq(p2);
ttwu_queue(p0, CPU1); ttwu_queue(p2, CPU1);
__ttwu_queue_wakelist(p0, CPU1);
WRITE_ONCE(CPU1->ttwu_pending, 1);
__smp_call_single_queue(CPU1, p0); => ttwu_list->p0
quiting cpuidle_idle_call()
__ttwu_queue_wakelist(p2, CPU1);
WRITE_ONCE(CPU1->ttwu_pending, 1);
ttwu_list->p2->p0 <= __smp_call_single_queue(CPU1, p2);
p0' => idle
sched_ttwu_pending()
enqueue_task(p2 and p0)
idle => p2
...
p2 time slice expires
...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<=== !!! p2 delays the wake up of p0' !!!
!!! causes long idle on CPU0 !!!
p2 => p0 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
p0 wakes up p0'
idle => p0'
Since there are many waker/wakee pairs in the system, the chain reaction
causes many CPUs to be victims. These idle CPUs wait for their waker to
be scheduled.
Tiancheng has mentioned the above issue here[1].
[Proposal]
The root cause is that there is no strict synchronization of
select_task_rq() and the set of ttwu_pending flag among several CPUs.
And this might be by design because the scheduler prefers parallel
wakeup.
Avoid this problem indirectly. If a system is busy, and if the waker
and wakee are both short duration tasks, wake up the wakee on current CPU.
The reason is that, if the waker is a short-duration task, it might
relinquish the CPU soon, and the wakee has the chance to be scheduled.
On the other hand, if the wakee is a short duration task, putting it on
non-idle CPU would bring minimal impact to the running task. No idle
core in the system indicates that this mechanism should not inhibit
spreading the tasks if the system is not busy.
This wake up strategy can be viewed as dynamic WF_SYNC. Except that
WF_SYNC does not treat non-idle CPU as candidate CPU.
[Benchmark results]
The baseline is v6.2-rc1 tip:sched/core, on top of
Commit be06c7d02443a ("cpuidle: Fix poll_idle() noinstr annotation").
The test platform has 2 x 56C/112T and 224 CPUs in total. C-states
deeper than C1E are disabled. Turbo is disabled. CPU frequency governor
is performance.
will-it-scale
=============
case load baseline compare%
context_switch1 224 groups 1.00 +1262.06%
There is a huge improvement in fast context switch test case, especially
when the number of groups equals the CPUs.
netperf
=======
case load baseline(std%) compare%( std%)
TCP_RR 56-threads 1.00 ( 0.86) -0.16 ( 0.98)
TCP_RR 112-threads 1.00 ( 0.65) +0.24 ( 0.50)
TCP_RR 168-threads 1.00 ( 5.87) +4.99 ( 4.81)
TCP_RR 224-threads 1.00 ( 4.63) +687.45 ( 3.77)
TCP_RR 280-threads 1.00 ( 9.91) +0.39 ( 13.05)
TCP_RR 336-threads 1.00 ( 21.27) +0.08 ( 15.32)
TCP_RR 392-threads 1.00 ( 40.60) +20.30 ( 30.95)
TCP_RR 448-threads 1.00 ( 29.85) +0.05 ( 33.18)
UDP_RR 56-threads 1.00 ( 2.46) -0.19 ( 2.50)
UDP_RR 112-threads 1.00 ( 12.59) +0.00 ( 12.31)
UDP_RR 168-threads 1.00 ( 18.55) +6.33 ( 62.39)
UDP_RR 224-threads 1.00 ( 13.31) +131.74 ( 22.13)
UDP_RR 280-threads 1.00 ( 32.69) -0.54 ( 23.84)
UDP_RR 336-threads 1.00 ( 28.52) +0.14 ( 26.45)
UDP_RR 392-threads 1.00 ( 26.80) +0.23 ( 32.52)
UDP_RR 448-threads 1.00 ( 41.65) -0.20 ( 42.97)
There is significant 600+% improvement for TCP_RR and 100+% for UDP_RR
when the number of threads equals the CPUs.
tbench
======
case load baseline(std%) compare%( std%)
loopback 56-threads 1.00 ( 1.05) +0.56 ( 0.48)
loopback 112-threads 1.00 ( 1.04) +0.83 ( 0.65)
loopback 168-threads 1.00 ( 29.60) +37.37 ( 33.77)
loopback 224-threads 1.00 ( 0.22) +0.11 ( 0.02)
loopback 280-threads 1.00 ( 0.04) -0.11 ( 0.06)
loopback 336-threads 1.00 ( 0.10) -0.11 ( 0.11)
loopback 392-threads 1.00 ( 0.42) -0.06 ( 0.05)
loopback 448-threads 1.00 ( 0.08) +0.19 ( 0.07)
There is no noticeable impact on tbench. And there is run-to-run variance
in 168 threads case, with or without this patch applied. It might be
another issue and need to be investigated later.
hackbench
=========
case load baseline(std%) compare%( std%)
process-pipe 1-groups 1.00 ( 11.63) +10.24 ( 17.85)
process-sockets 1-groups 1.00 ( 15.36) -17.58 ( 20.96)
threads-pipe 1-groups 1.00 ( 2.78) +2.86 ( 4.14)
threads-sockets 1-groups 1.00 ( 1.44) -0.57 ( 1.09)
process-pipe 2-groups 1.00 ( 4.93) -3.48 ( 8.04)
process-sockets 2-groups 1.00 ( 2.44) -3.76 ( 2.34)
threads-pipe 2-groups 1.00 ( 2.26) +4.36 ( 1.77)
threads-sockets 2-groups 1.00 ( 2.50) +1.86 ( 4.46)
process-pipe 4-groups 1.00 ( 1.97) +13.06 ( 7.60)
process-sockets 4-groups 1.00 ( 0.11) -0.57 ( 0.66)
threads-pipe 4-groups 1.00 ( 2.48) +1.90 ( 3.81)
threads-sockets 4-groups 1.00 ( 2.41) +0.28 ( 1.78)
process-pipe 8-groups 1.00 ( 1.45) +1.62 ( 0.13)
process-sockets 8-groups 1.00 ( 0.21) +0.05 ( 0.33)
threads-pipe 8-groups 1.00 ( 0.36) -1.19 ( 0.85)
threads-sockets 8-groups 1.00 ( 0.39) +1.03 ( 0.33)
Overall there is no noticeable impact on hackbench. There is a large
run-to-run variance when the load is low, with or without this patch
applied. Similar to tbench, this issue needs to be investigated too.
schbench
========
case load baseline(std%) compare%( std%)
normal 1-mthreads 1.00 ( 0.53) -0.22 ( 1.33)
normal 2-mthreads 1.00 ( 3.04) -3.53 ( 4.88)
normal 4-mthreads 1.00 ( 2.28) +1.73 ( 1.66)
normal 8-mthreads 1.00 ( 2.18) -1.75 ( 1.42)
There should be no impact on schbench in theory, because the default task
duration of schbench is 30 ms, which is much longer than the short task
threshold.
[Limitations/Miscellaneous]
[a]
Peter has suggested[2] comparing task duration with the cost of searching
for an idle CPU. If the latter is higher, then give up the scan, to
achieve better task affine. However, this method does not fit in the case
encountered in this patch. Because there are plenty of (fast)idle CPUs in
the system, it will not take too long to find an idle CPU. The bottleneck is
caused by the race condition mentioned above.
[b]
The short task threshold is sysctl_sched_min_granularity / 8.
According to get_update_sysctl_factor(), the sysctl_sched_min_granularity
could be 0.75 msec * 4 for SCHED_TUNABLESCALING_LOG,
or 0.75 msec * ncpus for SCHED_TUNABLESCALING_LINEAR.
Choosing 8 as the divisor is a trade-off. Thanks Honglei for pointing
this out.
[c]
SIS_SHORT leverages SIS_PROP to do better task placement. If the scan
number suggested by SIS_PROP is smaller than 60% of llc_weight, it
indicates that the util_avg% of the LLC domain is higher than 50%.
The 50% util_avg indicates a half-busy LLC domain, which makes a double
confirm with !has_idle_core, to not stack tasks if the system has idle
CPUs. System busier than this could lower its bar to choose a
compromised "idle" CPU.
[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://lore.kernel.org/lkml/Y2O8a%[email protected]/
Suggested-by: Tim Chen <[email protected]>
Suggested-by: K Prateek Nayak <[email protected]>
Tested-by: kernel test robot <[email protected]>
Signed-off-by: Chen Yu <[email protected]>
---
kernel/sched/fair.c | 26 ++++++++++++++++++++++++++
kernel/sched/features.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index aa16611c7263..d50097e5fcc1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6489,6 +6489,20 @@ static int wake_wide(struct task_struct *p)
return 1;
}
+/*
+ * If a task switches in and then voluntarily relinquishes the
+ * CPU quickly, it is regarded as a short duration task.
+ *
+ * SIS_SHORT tries to wake up the short wakee on current CPU. This
+ * aims to avoid race condition among CPUs due to frequent context
+ * switch.
+ */
+static inline int is_short_task(struct task_struct *p)
+{
+ return sched_feat(SIS_SHORT) && p->se.dur_avg &&
+ ((p->se.dur_avg * 8) < sysctl_sched_min_granularity);
+}
+
/*
* The purpose of wake_affine() is to quickly determine on which CPU we can run
* soonest. For the purpose of speed we only consider the waking and previous
@@ -6525,6 +6539,11 @@ wake_affine_idle(int this_cpu, int prev_cpu, int sync)
if (available_idle_cpu(prev_cpu))
return prev_cpu;
+ /* The only running task is a short duration one. */
+ if (cpu_rq(this_cpu)->nr_running == 1 &&
+ is_short_task(rcu_dereference(cpu_curr(this_cpu))))
+ return this_cpu;
+
return nr_cpumask_bits;
}
@@ -6899,6 +6918,13 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, bool
/* overloaded LLC is unlikely to have idle cpu/core */
if (nr == 1)
return -1;
+
+ if (!has_idle_core && this == target &&
+ (5 * nr < 3 * sd->span_weight) &&
+ cpu_rq(target)->nr_running <= 1 &&
+ is_short_task(p) &&
+ is_short_task(rcu_dereference(cpu_curr(target))))
+ return target;
}
}
diff --git a/kernel/sched/features.h b/kernel/sched/features.h
index ee7f23c76bd3..efdc29c42161 100644
--- a/kernel/sched/features.h
+++ b/kernel/sched/features.h
@@ -62,6 +62,7 @@ SCHED_FEAT(TTWU_QUEUE, true)
*/
SCHED_FEAT(SIS_PROP, false)
SCHED_FEAT(SIS_UTIL, true)
+SCHED_FEAT(SIS_SHORT, true)
/*
* Issue a WARN when we do multiple update_rq_clock() calls
--
2.25.1