Lines Matching full:cpu
2 CPU hotplug in the Kernel
18 insertion and removal require support for CPU hotplug.
21 provisioning reasons, or for RAS purposes to keep an offending CPU off
22 system execution path. Hence the need for CPU hotplug support in the
25 A more novel use of CPU-hotplug support is its use today in suspend resume
65 CPU maps
78 after a CPU is available for kernel scheduling and ready to receive
79 interrupts from devices. Its cleared when a CPU is brought down using
81 migrated to another target CPU.
91 You really don't need to manipulate any of the system CPU maps. They should
92 be read-only for most use. When setting up per-cpu resources almost always use
94 ``for_each_cpu()`` can be used to iterate over a custom CPU mask.
99 Using CPU hotplug
105 $ ls -lh /sys/devices/system/cpu
121 The files *offline*, *online*, *possible*, *present* represent the CPU masks.
122 Each CPU folder contains an *online* file which controls the logical on (1) and
125 $ echo 0 > /sys/devices/system/cpu/cpu4/online
126 smpboot: CPU 4 is now offline
128 Once the CPU is shutdown, it will be removed from */proc/interrupts*,
132 $ echo 1 > /sys/devices/system/cpu/cpu4/online
135 The CPU is usable again. This should work on all CPUs. CPU0 is often special
136 and excluded from CPU hotplug. On X86 the kernel option
147 The CPU hotplug coordination
152 Once a CPU has been logically shutdown the teardown callbacks of registered
158 * All processes are migrated away from this outgoing CPU to new CPUs.
159 The new CPU is chosen from each process' current cpuset, which may be
161 * All interrupts targeted to this CPU are migrated to a new CPU
162 * timers are also migrated to a new CPU
168 It is possible to receive notifications once a CPU is offline or onlined. This
182 once a CPU is brought online and *Y_prepare_down* will be invoked when a
183 CPU is shutdown. All resources which were previously allocated in
225 removal of a state because usually the operation needs to performed once a CPU
230 ``get_online_cpus()`` and ``put_online_cpus()`` should be used to inhibit CPU
239 CPU is up.
241 just the after the CPU has been brought up. The interrupts are off and
242 the scheduler is not yet active on this CPU. Starting with *CPUHP_AP_OFFLINE*
243 the callbacks are invoked on the target CPU.
246 * The states are invoked in the reverse order on CPU shutdown starting with
248 invoked on the CPU that will be shutdown until *CPUHP_AP_OFFLINE*.
259 shutdown a CPU and then put it online again. It is also possible to put the CPU
264 All registered states are enumerated in ``/sys/devices/system/cpu/hotplug/states``: ::
266 $ tail /sys/devices/system/cpu/hotplug/states
270 141: acpi/cpu-drv:online
280 $ cat /sys/devices/system/cpu/cpu4/hotplug/state
282 $ echo 140 > /sys/devices/system/cpu/cpu4/hotplug/target
283 $ cat /sys/devices/system/cpu/cpu4/hotplug/state
289 $ echo 169 > /sys/devices/system/cpu/cpu4/hotplug/target
290 $ cat /sys/devices/system/cpu/cpu4/hotplug/state
295 # TASK-PID CPU# TIMESTAMP FUNCTION
297 bash-394 [001] 22.976: cpuhp_enter: cpu: 0004 target: 140 step: 169 (cpuhp_kick_ap_work)
298 cpuhp/4-31 [004] 22.977: cpuhp_enter: cpu: 0004 target: 140 step: 168 (sched_cpu_deactivate)
299 cpuhp/4-31 [004] 22.990: cpuhp_exit: cpu: 0004 state: 168 step: 168 ret: 0
300 cpuhp/4-31 [004] 22.991: cpuhp_enter: cpu: 0004 target: 140 step: 144 (mce_cpu_pre_down)
301 cpuhp/4-31 [004] 22.992: cpuhp_exit: cpu: 0004 state: 144 step: 144 ret: 0
302 …cpuhp/4-31 [004] 22.993: cpuhp_multi_enter: cpu: 0004 target: 140 step: 143 (virtnet_cpu_down_p…
303 cpuhp/4-31 [004] 22.994: cpuhp_exit: cpu: 0004 state: 143 step: 143 ret: 0
304 cpuhp/4-31 [004] 22.995: cpuhp_enter: cpu: 0004 target: 140 step: 142 (cacheinfo_cpu_pre_down)
305 cpuhp/4-31 [004] 22.996: cpuhp_exit: cpu: 0004 state: 142 step: 142 ret: 0
306 bash-394 [001] 22.997: cpuhp_exit: cpu: 0004 state: 140 step: 169 ret: 0
307 bash-394 [005] 95.540: cpuhp_enter: cpu: 0004 target: 169 step: 140 (cpuhp_kick_ap_work)
308 cpuhp/4-31 [004] 95.541: cpuhp_enter: cpu: 0004 target: 169 step: 141 (acpi_soft_cpu_online)
309 cpuhp/4-31 [004] 95.542: cpuhp_exit: cpu: 0004 state: 141 step: 141 ret: 0
310 cpuhp/4-31 [004] 95.543: cpuhp_enter: cpu: 0004 target: 169 step: 142 (cacheinfo_cpu_online)
311 cpuhp/4-31 [004] 95.544: cpuhp_exit: cpu: 0004 state: 142 step: 142 ret: 0
312 …cpuhp/4-31 [004] 95.545: cpuhp_multi_enter: cpu: 0004 target: 169 step: 143 (virtnet_cpu_online)
313 cpuhp/4-31 [004] 95.546: cpuhp_exit: cpu: 0004 state: 143 step: 143 ret: 0
314 cpuhp/4-31 [004] 95.547: cpuhp_enter: cpu: 0004 target: 169 step: 144 (mce_cpu_online)
315 cpuhp/4-31 [004] 95.548: cpuhp_exit: cpu: 0004 state: 144 step: 144 ret: 0
316 cpuhp/4-31 [004] 95.549: cpuhp_enter: cpu: 0004 target: 169 step: 145 (console_cpu_notify)
317 cpuhp/4-31 [004] 95.550: cpuhp_exit: cpu: 0004 state: 145 step: 145 ret: 0
318 cpuhp/4-31 [004] 95.551: cpuhp_enter: cpu: 0004 target: 169 step: 168 (sched_cpu_activate)
319 cpuhp/4-31 [004] 95.552: cpuhp_exit: cpu: 0004 state: 168 step: 168 ret: 0
320 bash-394 [005] 95.553: cpuhp_exit: cpu: 0004 state: 169 step: 140 ret: 0
334 Arch interface to bring up a CPU
337 Arch interface to shutdown a CPU, no more interrupts can be handled by the
341 This actually supposed to ensure death of the CPU. Actually look at some
342 example code in other arch that implement CPU hotplug. The processor is taken
349 After CPU successfully onlined or offline udev events are sent. A udev rule like: ::
351 …SUBSYSTEM=="cpu", DRIVERS=="processor", DEVPATH=="/devices/system/cpu/*", RUN+="the_hotplug_receiv…
359 echo "CPU ${DEVPATH##*/} offline"
363 echo "CPU ${DEVPATH##*/} online"