Lines Matching refs:CPU
2 CPU hotplug in the Kernel
19 insertion and removal require support for CPU hotplug.
22 provisioning reasons, or for RAS purposes to keep an offending CPU off
23 system execution path. Hence the need for CPU hotplug support in the
26 A more novel use of CPU-hotplug support is its use today in suspend resume
59 CPU maps
72 after a CPU is available for kernel scheduling and ready to receive
73 interrupts from devices. Its cleared when a CPU is brought down using
75 migrated to another target CPU.
85 You really don't need to manipulate any of the system CPU maps. They should
88 ``for_each_cpu()`` can be used to iterate over a custom CPU mask.
93 Using CPU hotplug
116 The files *offline*, *online*, *possible*, *present* represent the CPU masks.
117 Each CPU folder contains an *online* file which controls the logical on (1) and
121 smpboot: CPU 4 is now offline
123 Once the CPU is shutdown, it will be removed from */proc/interrupts*,
130 The CPU is usable again. This should work on all CPUs. CPU0 is often special
131 and excluded from CPU hotplug. On X86 the kernel option
142 The CPU hotplug coordination
148 Once a CPU has been logically shutdown the teardown callbacks of registered
154 * All processes are migrated away from this outgoing CPU to new CPUs.
155 The new CPU is chosen from each process' current cpuset, which may be
157 * All interrupts targeted to this CPU are migrated to a new CPU
158 * timers are also migrated to a new CPU
163 The CPU hotplug API
166 CPU hotplug state machine
169 CPU hotplug uses a trivial state machine with a linear state space from
173 When a CPU is onlined, the startup callbacks are invoked sequentially until
178 When a CPU is offlined the teardown callbacks are invoked in the reverse
184 operations (CPU online or CPU offline) then the other not-required callback
194 The startup callbacks in this section are invoked before the CPU is
195 started during a CPU online operation. The teardown callbacks are invoked
196 after the CPU has become dysfunctional during a CPU offline operation.
198 The callbacks are invoked on a control CPU as they can't obviously run on
199 the hotplugged CPU which is either not yet started or has become
203 bring a CPU successfully online. The teardown callbacks are used to free
204 resources or to move pending work to an online CPU after the hotplugged
205 CPU became dysfunctional.
207 The startup callbacks are allowed to fail. If a callback fails, the CPU
208 online operation is aborted and the CPU is brought down to the previous
218 The startup callbacks in this section are invoked on the hotplugged CPU
219 with interrupts disabled during a CPU online operation in the early CPU
221 on the hotplugged CPU during a CPU offline operation shortly before the
222 CPU is completely shut down.
234 The startup callbacks in this section are invoked on the hotplugged CPU
235 during a CPU online operation. The teardown callbacks are invoked on the
236 hotplugged CPU during a CPU offline operation.
238 The callbacks are invoked in the context of the per CPU hotplug thread,
239 which is pinned on the hotplugged CPU. The callbacks are invoked with
243 operation is aborted and the CPU is brought back to the previous state.
245 CPU online/offline operations
336 The CPU hotplug state machine stops right here and does not try to go back
346 Lather, rinse and repeat. In this case the CPU left in state::
356 There are two ways to allocate a CPU hotplug state:
361 ordering requirements versus other CPU hotplug states. E.g. the PERF core
363 callbacks during a CPU online operation. During a CPU offline operation
373 up at runtime and are part of the initializer of the CPU hotplug state
386 Setup of a CPU hotplug state
397 CPU hotplug state callbacks need to be invoked for each instance, the CPU
400 serialized against CPU hotplug operations and provide the automatic
440 invoked during a CPU online operation. If the usage site does not require a
444 be invoked during a CPU offline operation. If the usage site does not
456 the current CPU (PREPARE section) or on each online CPU (ONLINE
457 section) in the context of the CPU's hotplug thread.
459 If a callback fails for CPU N then the teardown callback for CPU
464 The state setup and the callback invocations are serialized against CPU
465 hotplug operations. If the setup function has to be called from a CPU
467 used. These functions cannot be used from within CPU hotplug callbacks.
486 Removal of a CPU hotplug state
509 callback is either invoked on the current CPU (PREPARE section) or on
510 each online CPU (ONLINE section) in the context of the CPU's hotplug
515 The state removal and the callback invocations are serialized against CPU
516 hotplug operations. If the remove function has to be called from a CPU
518 used. These functions cannot be used from within CPU hotplug callbacks.
549 the callback is either invoked on the current CPU (PREPARE section) or
550 on each online CPU (ONLINE section) in the context of the CPU's hotplug
553 If a callback fails for CPU N then the teardown callback for CPU
575 section the callback is either invoked on the current CPU (PREPARE
576 section) or on each online CPU (ONLINE section) in the context of the
577 CPU's hotplug thread.
582 serialized against CPU hotplug operations. These functions cannot be used
583 from within CPU hotplug callbacks and CPU hotplug read locked regions.
641 shutdown a CPU and then put it online again. It is also possible to put the CPU
677 # TASK-PID CPU# TIMESTAMP FUNCTION
717 Arch interface to bring up a CPU
720 Arch interface to shutdown a CPU, no more interrupts can be handled by the
724 This actually supposed to ensure death of the CPU. Actually look at some
725 example code in other arch that implement CPU hotplug. The processor is taken
733 After CPU successfully onlined or offline udev events are sent. A udev rule like::
743 echo "CPU ${DEVPATH##*/} offline"
747 echo "CPU ${DEVPATH##*/} online"