Lines Matching +full:back +full:- +full:to +full:- +full:back
2 Reducing OS jitter due to per-cpu kthreads
5 This document lists per-CPU kthreads in the Linux kernel and presents
6 options to control their OS jitter. Note that non-per-CPU kthreads are
7 not listed here. To reduce OS jitter from non-per-CPU kthreads, bind
8 them to a "housekeeping" CPU dedicated to such work.
13 - Documentation/core-api/irq/irq-affinity.rst: Binding interrupts to sets of CPUs.
15 - Documentation/admin-guide/cgroup-v1: Using cgroups to bind tasks to sets of CPUs.
17 - man taskset: Using the taskset command to bind tasks to sets
20 - man sched_setaffinity: Using the sched_setaffinity() system
21 call to bind tasks to sets of CPUs.
23 - /sys/devices/system/cpu/cpuN/online: Control CPU N's hotplug state,
24 writing "0" to offline and "1" to online.
26 - In order to locate kernel-generated OS jitter on CPU N:
41 Periodically process Infiniband-related work.
43 To reduce its OS jitter, do any of the following:
46 that does not require per-CPU kthreads. This will prevent these
50 2. Do all eHCA-Infiniband-related work on other CPUs, including
52 3. Rework the eHCA driver so that its per-CPU kthreads are
57 irq/%d-%s
62 To reduce its OS jitter, do the following:
64 1. Use irq affinity to force the irq threads to execute on
73 To reduce its OS jitter, do one of the following:
77 2. Use irq affinity to force Bluetooth-related interrupts to
87 To reduce its OS jitter, each softirq vector must be handled
91 -------------
95 1. To the extent possible, keep the CPU out of the kernel when it
96 is non-idle, for example, by avoiding system calls and by forcing
97 both kernel threads and interrupts to execute elsewhere.
99 the CPU offline, then bring it back online. This forces
100 recurring timers to migrate elsewhere. If you are concerned
102 first one back online. Once you have onlined the CPUs in question,
104 timer back onto one of the CPUs in question.
107 ---------------------------------
113 3. Once your application has started, prevent CPU-hotplug operations
114 from being initiated from tasks that might run on the CPU to
115 be de-jittered. (It is OK to force this CPU offline and then
116 bring it back online before you start your application.)
119 -------------
123 1. Force block-device interrupts onto some other CPU.
125 3. Once your application has started, prevent CPU-hotplug operations
126 from being initiated from tasks that might run on the CPU to
127 be de-jittered. (It is OK to force this CPU offline and then
128 bring it back online before you start your application.)
131 ----------------
135 1. Force block-device interrupts onto some other CPU.
136 2. Initiate any block I/O and block-I/O polling on other CPUs.
137 3. Once your application has started, prevent CPU-hotplug operations
138 from being initiated from tasks that might run on the CPU to
139 be de-jittered. (It is OK to force this CPU offline and then
140 bring it back online before you start your application.)
143 ---------------
148 calls to things like tasklet_schedule().)
149 2. Convert all drivers that you must use from tasklets to workqueues.
154 -------------
158 1. Avoid sending scheduler IPIs to the CPU to be de-jittered,
160 on that CPU. If a thread that expects to run on the de-jittered
163 2. CONFIG_NO_HZ_FULL=y and ensure that the CPU to be de-jittered
164 is marked as an adaptive-ticks CPU using the "nohz_full="
165 boot parameter. This reduces the number of scheduler-clock
166 interrupts that the de-jittered CPU receives, minimizing its
167 chances of being selected to do the load balancing work that
169 3. To the extent possible, keep the CPU out of the kernel when it
170 is non-idle, for example, by avoiding system calls and by
171 forcing both kernel threads and interrupts to execute elsewhere.
172 This further reduces the number of scheduler-clock interrupts
173 received by the de-jittered CPU.
176 ---------------
180 1. To the extent possible, keep the CPU out of the kernel when it
181 is non-idle. For example, avoid system calls and force both
182 kernel threads and interrupts to execute elsewhere.
184 CPU offline, then bring it back online. This forces recurring
185 timers to migrate elsewhere. If you are concerned with multiple
187 back online. Once you have onlined the CPUs in question, do not
189 back onto one of the CPUs in question.
192 -----------
196 1. Offload callbacks and keep the CPU in either dyntick-idle or
197 adaptive-ticks state by doing all of the following:
199 a. CONFIG_NO_HZ_FULL=y and ensure that the CPU to be
200 de-jittered is marked as an adaptive-ticks CPU using the
201 "nohz_full=" boot parameter. Bind the rcuo kthreads to
203 b. To the extent possible, keep the CPU out of the kernel
204 when it is non-idle, for example, by avoiding system
206 to execute elsewhere.
208 2. Enable RCU to do its processing remotely via dyntick-idle by
213 CPUs to detect that it has passed through an RCU quiescent
215 userspace execution also allows other CPUs to detect that
217 c. To the extent possible, keep the CPU out of the kernel
218 when it is non-idle, for example, by avoiding system
220 to execute elsewhere.
228 To reduce its OS jitter, do any of the following:
230 1. Run your workload at a real-time priority, which will allow
233 by passing the WQ_SYSFS to that workqueue's alloc_workqueue().
234 Such a workqueue can be confined to a given subset of the
238 maintainer would like to caution people against indiscriminately
240 caution is that it is easy to add WQ_SYSFS, but because sysfs is
242 to remove it, even if its addition was a mistake.
243 3. Do any of the following needed to avoid jitter that your
248 b. Limit your CPU frequency so that a CPU-frequency
252 be able to build your kernel with CONFIG_CPU_FREQ=n to
253 avoid the CPU-frequency governor periodically running
256 WARNING: Please check your CPU specifications to
258 c. As of v3.18, Christoph Lameter's on-demand vmstat workers
259 commit prevents OS jitter due to vmstat_update() on
261 to entirely get rid of the OS jitter, but you can
262 decrease its frequency by writing a large value to
265 will make your virtual-memory statistics update more
267 a real-time priority, thus preempting vmstat_update(),
268 but if your workload is CPU-bound, this is a bad idea.
270 (based on an earlier one from Gilad Ben-Yossef) that
272 …workloads at https://lore.kernel.org/r/00000140e9dfd6bd-40db3d4f-c1be-434f-8132-7820f81bb586-00000…
273 d. If running on high-end powerpc servers, build with
278 due to the rtas_event_scan() function.
279 WARNING: Please check your CPU specifications to
282 CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from
284 WARNING: Please check your CPU specifications to
287 CONFIG_PMAC_RACKMETER=n to disable the CPU-meter,
296 To reduce its OS jitter, do at least one of the following:
309 to OS jitter. This approach prevents the rcuc/%u kthreads from
310 having any work to do, so that they are never awakened.
315 to do.
323 To reduce its OS jitter, do at least one of the following:
325 1. Use affinity, cgroups, or other mechanism to force these kthreads
326 to execute on some other CPU.
330 shift it to RCU_SOFTIRQ.