Lines Matching +full:cpu +full:- +full:2
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
23 - /sys/devices/system/cpu/cpuN/online: Control CPU N's hotplug state,
26 - In order to locate kernel-generated OS jitter on CPU N:
41 Periodically process Infiniband-related work.
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
65 some other CPU.
77 2. Use irq affinity to force Bluetooth-related interrupts to
78 occur on some other CPU and furthermore initiate all
79 Bluetooth activity on some other CPU.
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
98 2. Build with CONFIG_HOTPLUG_CPU=y. After boot completes, force
99 the CPU offline, then bring it back online. This forces
107 ---------------------------------
112 2. Initiate any network I/O on other CPUs.
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
119 -------------
123 1. Force block-device interrupts onto some other CPU.
124 2. Initiate any block I/O on other CPUs.
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
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
143 ---------------
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
161 CPU awakens, the scheduler will send an IPI that can result in
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
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
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
183 2. Build with CONFIG_HOTPLUG_CPU=y. Once boot completes, force the
184 CPU offline, then bring it back online. This forces recurring
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
203 b. To the extent possible, keep the CPU out of the kernel
204 when it is non-idle, for example, by avoiding system
208 2. Enable RCU to do its processing remotely via dyntick-idle by
212 b. Ensure that the CPU goes idle frequently, allowing other
216 the CPU in question has passed through a quiescent state.
217 c. To the extent possible, keep the CPU out of the kernel
218 when it is non-idle, for example, by avoiding system
223 kworker/%u:%d%s (cpu, id, priority)
230 1. Run your workload at a real-time priority, which will allow
232 2. A given workqueue can be made visible in the sysfs filesystem
248 b. Limit your CPU frequency so that a CPU-frequency
251 correctly, and if you CPU architecture permits, you should
253 avoid the CPU-frequency governor periodically running
254 on each CPU, including cs_dbs_timer() and od_dbs_timer().
256 WARNING: Please check your CPU specifications to
258 c. As of v3.18, Christoph Lameter's on-demand vmstat workers
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
275 daemon from running on each CPU every second or so.
279 WARNING: Please check your CPU specifications to
284 WARNING: Please check your CPU specifications to
287 CONFIG_PMAC_RACKMETER=n to disable the CPU-meter,
302 2. Build the kernel with CONFIG_RCU_BOOST=n. This prevents these
311 4. Ensure that the CPU never enters the kernel, and, in particular,
312 avoid initiating any CPU hotplug operations on this CPU. This is
314 CPU, again preventing the rcuc/%u kthreads from having any work
321 Offload RCU callbacks from the corresponding CPU.
326 to execute on some other CPU.
327 2. Build with CONFIG_RCU_NOCB_CPU=n, which will prevent these