Root/
1 | CPU hotplug Support in Linux(tm) Kernel |
2 | |
3 | Maintainers: |
4 | CPU Hotplug Core: |
5 | Rusty Russell <rusty@rustycorp.com.au> |
6 | Srivatsa Vaddagiri <vatsa@in.ibm.com> |
7 | i386: |
8 | Zwane Mwaikambo <zwane@arm.linux.org.uk> |
9 | ppc64: |
10 | Nathan Lynch <nathanl@austin.ibm.com> |
11 | Joel Schopp <jschopp@austin.ibm.com> |
12 | ia64/x86_64: |
13 | Ashok Raj <ashok.raj@intel.com> |
14 | s390: |
15 | Heiko Carstens <heiko.carstens@de.ibm.com> |
16 | |
17 | Authors: Ashok Raj <ashok.raj@intel.com> |
18 | Lots of feedback: Nathan Lynch <nathanl@austin.ibm.com>, |
19 | Joel Schopp <jschopp@austin.ibm.com> |
20 | |
21 | Introduction |
22 | |
23 | Modern advances in system architectures have introduced advanced error |
24 | reporting and correction capabilities in processors. CPU architectures permit |
25 | partitioning support, where compute resources of a single CPU could be made |
26 | available to virtual machine environments. There are couple OEMS that |
27 | support NUMA hardware which are hot pluggable as well, where physical |
28 | node insertion and removal require support for CPU hotplug. |
29 | |
30 | Such advances require CPUs available to a kernel to be removed either for |
31 | provisioning reasons, or for RAS purposes to keep an offending CPU off |
32 | system execution path. Hence the need for CPU hotplug support in the |
33 | Linux kernel. |
34 | |
35 | A more novel use of CPU-hotplug support is its use today in suspend |
36 | resume support for SMP. Dual-core and HT support makes even |
37 | a laptop run SMP kernels which didn't support these methods. SMP support |
38 | for suspend/resume is a work in progress. |
39 | |
40 | General Stuff about CPU Hotplug |
41 | -------------------------------- |
42 | |
43 | Command Line Switches |
44 | --------------------- |
45 | maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using |
46 | maxcpus=2 will only boot 2. You can choose to bring the |
47 | other cpus later online, read FAQ's for more info. |
48 | |
49 | additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets |
50 | cpu_possible_map = cpu_present_map + additional_cpus |
51 | |
52 | (*) Option valid only for following architectures |
53 | - ia64 |
54 | |
55 | ia64 uses the number of disabled local apics in ACPI tables MADT to |
56 | determine the number of potentially hot-pluggable cpus. The implementation |
57 | should only rely on this to count the # of cpus, but *MUST* not rely |
58 | on the apicid values in those tables for disabled apics. In the event |
59 | BIOS doesn't mark such hot-pluggable cpus as disabled entries, one could |
60 | use this parameter "additional_cpus=x" to represent those cpus in the |
61 | cpu_possible_map. |
62 | |
63 | possible_cpus=n [s390,x86_64] use this to set hotpluggable cpus. |
64 | This option sets possible_cpus bits in |
65 | cpu_possible_map. Thus keeping the numbers of bits set |
66 | constant even if the machine gets rebooted. |
67 | |
68 | CPU maps and such |
69 | ----------------- |
70 | [More on cpumaps and primitive to manipulate, please check |
71 | include/linux/cpumask.h that has more descriptive text.] |
72 | |
73 | cpu_possible_map: Bitmap of possible CPUs that can ever be available in the |
74 | system. This is used to allocate some boot time memory for per_cpu variables |
75 | that aren't designed to grow/shrink as CPUs are made available or removed. |
76 | Once set during boot time discovery phase, the map is static, i.e no bits |
77 | are added or removed anytime. Trimming it accurately for your system needs |
78 | upfront can save some boot time memory. See below for how we use heuristics |
79 | in x86_64 case to keep this under check. |
80 | |
81 | cpu_online_map: Bitmap of all CPUs currently online. Its set in __cpu_up() |
82 | after a cpu is available for kernel scheduling and ready to receive |
83 | interrupts from devices. Its cleared when a cpu is brought down using |
84 | __cpu_disable(), before which all OS services including interrupts are |
85 | migrated to another target CPU. |
86 | |
87 | cpu_present_map: Bitmap of CPUs currently present in the system. Not all |
88 | of them may be online. When physical hotplug is processed by the relevant |
89 | subsystem (e.g ACPI) can change and new bit either be added or removed |
90 | from the map depending on the event is hot-add/hot-remove. There are currently |
91 | no locking rules as of now. Typical usage is to init topology during boot, |
92 | at which time hotplug is disabled. |
93 | |
94 | You really dont need to manipulate any of the system cpu maps. They should |
95 | be read-only for most use. When setting up per-cpu resources almost always use |
96 | cpu_possible_map/for_each_possible_cpu() to iterate. |
97 | |
98 | Never use anything other than cpumask_t to represent bitmap of CPUs. |
99 | |
100 | #include <linux/cpumask.h> |
101 | |
102 | for_each_possible_cpu - Iterate over cpu_possible_map |
103 | for_each_online_cpu - Iterate over cpu_online_map |
104 | for_each_present_cpu - Iterate over cpu_present_map |
105 | for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask. |
106 | |
107 | #include <linux/cpu.h> |
108 | get_online_cpus() and put_online_cpus(): |
109 | |
110 | The above calls are used to inhibit cpu hotplug operations. While the |
111 | cpu_hotplug.refcount is non zero, the cpu_online_map will not change. |
112 | If you merely need to avoid cpus going away, you could also use |
113 | preempt_disable() and preempt_enable() for those sections. |
114 | Just remember the critical section cannot call any |
115 | function that can sleep or schedule this process away. The preempt_disable() |
116 | will work as long as stop_machine_run() is used to take a cpu down. |
117 | |
118 | CPU Hotplug - Frequently Asked Questions. |
119 | |
120 | Q: How to enable my kernel to support CPU hotplug? |
121 | A: When doing make defconfig, Enable CPU hotplug support |
122 | |
123 | "Processor type and Features" -> Support for Hotpluggable CPUs |
124 | |
125 | Make sure that you have CONFIG_HOTPLUG, and CONFIG_SMP turned on as well. |
126 | |
127 | You would need to enable CONFIG_HOTPLUG_CPU for SMP suspend/resume support |
128 | as well. |
129 | |
130 | Q: What architectures support CPU hotplug? |
131 | A: As of 2.6.14, the following architectures support CPU hotplug. |
132 | |
133 | i386 (Intel), ppc, ppc64, parisc, s390, ia64 and x86_64 |
134 | |
135 | Q: How to test if hotplug is supported on the newly built kernel? |
136 | A: You should now notice an entry in sysfs. |
137 | |
138 | Check if sysfs is mounted, using the "mount" command. You should notice |
139 | an entry as shown below in the output. |
140 | |
141 | .... |
142 | none on /sys type sysfs (rw) |
143 | .... |
144 | |
145 | If this is not mounted, do the following. |
146 | |
147 | #mkdir /sysfs |
148 | #mount -t sysfs sys /sys |
149 | |
150 | Now you should see entries for all present cpu, the following is an example |
151 | in a 8-way system. |
152 | |
153 | #pwd |
154 | #/sys/devices/system/cpu |
155 | #ls -l |
156 | total 0 |
157 | drwxr-xr-x 10 root root 0 Sep 19 07:44 . |
158 | drwxr-xr-x 13 root root 0 Sep 19 07:45 .. |
159 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu0 |
160 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu1 |
161 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu2 |
162 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu3 |
163 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu4 |
164 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu5 |
165 | drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu6 |
166 | drwxr-xr-x 3 root root 0 Sep 19 07:48 cpu7 |
167 | |
168 | Under each directory you would find an "online" file which is the control |
169 | file to logically online/offline a processor. |
170 | |
171 | Q: Does hot-add/hot-remove refer to physical add/remove of cpus? |
172 | A: The usage of hot-add/remove may not be very consistently used in the code. |
173 | CONFIG_HOTPLUG_CPU enables logical online/offline capability in the kernel. |
174 | To support physical addition/removal, one would need some BIOS hooks and |
175 | the platform should have something like an attention button in PCI hotplug. |
176 | CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs. |
177 | |
178 | Q: How do i logically offline a CPU? |
179 | A: Do the following. |
180 | |
181 | #echo 0 > /sys/devices/system/cpu/cpuX/online |
182 | |
183 | Once the logical offline is successful, check |
184 | |
185 | #cat /proc/interrupts |
186 | |
187 | You should now not see the CPU that you removed. Also online file will report |
188 | the state as 0 when a cpu if offline and 1 when its online. |
189 | |
190 | #To display the current cpu state. |
191 | #cat /sys/devices/system/cpu/cpuX/online |
192 | |
193 | Q: Why cant i remove CPU0 on some systems? |
194 | A: Some architectures may have some special dependency on a certain CPU. |
195 | |
196 | For e.g in IA64 platforms we have ability to sent platform interrupts to the |
197 | OS. a.k.a Corrected Platform Error Interrupts (CPEI). In current ACPI |
198 | specifications, we didn't have a way to change the target CPU. Hence if the |
199 | current ACPI version doesn't support such re-direction, we disable that CPU |
200 | by making it not-removable. |
201 | |
202 | In such cases you will also notice that the online file is missing under cpu0. |
203 | |
204 | Q: How do i find out if a particular CPU is not removable? |
205 | A: Depending on the implementation, some architectures may show this by the |
206 | absence of the "online" file. This is done if it can be determined ahead of |
207 | time that this CPU cannot be removed. |
208 | |
209 | In some situations, this can be a run time check, i.e if you try to remove the |
210 | last CPU, this will not be permitted. You can find such failures by |
211 | investigating the return value of the "echo" command. |
212 | |
213 | Q: What happens when a CPU is being logically offlined? |
214 | A: The following happen, listed in no particular order :-) |
215 | |
216 | - A notification is sent to in-kernel registered modules by sending an event |
217 | CPU_DOWN_PREPARE or CPU_DOWN_PREPARE_FROZEN, depending on whether or not the |
218 | CPU is being offlined while tasks are frozen due to a suspend operation in |
219 | progress |
220 | - All processes are migrated away from this outgoing CPU to new CPUs. |
221 | The new CPU is chosen from each process' current cpuset, which may be |
222 | a subset of all online CPUs. |
223 | - All interrupts targeted to this CPU is migrated to a new CPU |
224 | - timers/bottom half/task lets are also migrated to a new CPU |
225 | - Once all services are migrated, kernel calls an arch specific routine |
226 | __cpu_disable() to perform arch specific cleanup. |
227 | - Once this is successful, an event for successful cleanup is sent by an event |
228 | CPU_DEAD (or CPU_DEAD_FROZEN if tasks are frozen due to a suspend while the |
229 | CPU is being offlined). |
230 | |
231 | "It is expected that each service cleans up when the CPU_DOWN_PREPARE |
232 | notifier is called, when CPU_DEAD is called its expected there is nothing |
233 | running on behalf of this CPU that was offlined" |
234 | |
235 | Q: If i have some kernel code that needs to be aware of CPU arrival and |
236 | departure, how to i arrange for proper notification? |
237 | A: This is what you would need in your kernel code to receive notifications. |
238 | |
239 | #include <linux/cpu.h> |
240 | static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb, |
241 | unsigned long action, void *hcpu) |
242 | { |
243 | unsigned int cpu = (unsigned long)hcpu; |
244 | |
245 | switch (action) { |
246 | case CPU_ONLINE: |
247 | case CPU_ONLINE_FROZEN: |
248 | foobar_online_action(cpu); |
249 | break; |
250 | case CPU_DEAD: |
251 | case CPU_DEAD_FROZEN: |
252 | foobar_dead_action(cpu); |
253 | break; |
254 | } |
255 | return NOTIFY_OK; |
256 | } |
257 | |
258 | static struct notifier_block __cpuinitdata foobar_cpu_notifer = |
259 | { |
260 | .notifier_call = foobar_cpu_callback, |
261 | }; |
262 | |
263 | You need to call register_cpu_notifier() from your init function. |
264 | Init functions could be of two types: |
265 | 1. early init (init function called when only the boot processor is online). |
266 | 2. late init (init function called _after_ all the CPUs are online). |
267 | |
268 | For the first case, you should add the following to your init function |
269 | |
270 | register_cpu_notifier(&foobar_cpu_notifier); |
271 | |
272 | For the second case, you should add the following to your init function |
273 | |
274 | register_hotcpu_notifier(&foobar_cpu_notifier); |
275 | |
276 | You can fail PREPARE notifiers if something doesn't work to prepare resources. |
277 | This will stop the activity and send a following CANCELED event back. |
278 | |
279 | CPU_DEAD should not be failed, its just a goodness indication, but bad |
280 | things will happen if a notifier in path sent a BAD notify code. |
281 | |
282 | Q: I don't see my action being called for all CPUs already up and running? |
283 | A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined. |
284 | If you need to perform some action for each cpu already in the system, then |
285 | |
286 | for_each_online_cpu(i) { |
287 | foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i); |
288 | foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i); |
289 | } |
290 | |
291 | Q: If i would like to develop cpu hotplug support for a new architecture, |
292 | what do i need at a minimum? |
293 | A: The following are what is required for CPU hotplug infrastructure to work |
294 | correctly. |
295 | |
296 | - Make sure you have an entry in Kconfig to enable CONFIG_HOTPLUG_CPU |
297 | - __cpu_up() - Arch interface to bring up a CPU |
298 | - __cpu_disable() - Arch interface to shutdown a CPU, no more interrupts |
299 | can be handled by the kernel after the routine |
300 | returns. Including local APIC timers etc are |
301 | shutdown. |
302 | - __cpu_die() - This actually supposed to ensure death of the CPU. |
303 | Actually look at some example code in other arch |
304 | that implement CPU hotplug. The processor is taken |
305 | down from the idle() loop for that specific |
306 | architecture. __cpu_die() typically waits for some |
307 | per_cpu state to be set, to ensure the processor |
308 | dead routine is called to be sure positively. |
309 | |
310 | Q: I need to ensure that a particular cpu is not removed when there is some |
311 | work specific to this cpu is in progress. |
312 | A: First switch the current thread context to preferred cpu |
313 | |
314 | int my_func_on_cpu(int cpu) |
315 | { |
316 | cpumask_t saved_mask, new_mask = CPU_MASK_NONE; |
317 | int curr_cpu, err = 0; |
318 | |
319 | saved_mask = current->cpus_allowed; |
320 | cpu_set(cpu, new_mask); |
321 | err = set_cpus_allowed(current, new_mask); |
322 | |
323 | if (err) |
324 | return err; |
325 | |
326 | /* |
327 | * If we got scheduled out just after the return from |
328 | * set_cpus_allowed() before running the work, this ensures |
329 | * we stay locked. |
330 | */ |
331 | curr_cpu = get_cpu(); |
332 | |
333 | if (curr_cpu != cpu) { |
334 | err = -EAGAIN; |
335 | goto ret; |
336 | } else { |
337 | /* |
338 | * Do work : But cant sleep, since get_cpu() disables preempt |
339 | */ |
340 | } |
341 | ret: |
342 | put_cpu(); |
343 | set_cpus_allowed(current, saved_mask); |
344 | return err; |
345 | } |
346 | |
347 | |
348 | Q: How do we determine how many CPUs are available for hotplug. |
349 | A: There is no clear spec defined way from ACPI that can give us that |
350 | information today. Based on some input from Natalie of Unisys, |
351 | that the ACPI MADT (Multiple APIC Description Tables) marks those possible |
352 | CPUs in a system with disabled status. |
353 | |
354 | Andi implemented some simple heuristics that count the number of disabled |
355 | CPUs in MADT as hotpluggable CPUS. In the case there are no disabled CPUS |
356 | we assume 1/2 the number of CPUs currently present can be hotplugged. |
357 | |
358 | Caveat: Today's ACPI MADT can only provide 256 entries since the apicid field |
359 | in MADT is only 8 bits. |
360 | |
361 | User Space Notification |
362 | |
363 | Hotplug support for devices is common in Linux today. Its being used today to |
364 | support automatic configuration of network, usb and pci devices. A hotplug |
365 | event can be used to invoke an agent script to perform the configuration task. |
366 | |
367 | You can add /etc/hotplug/cpu.agent to handle hotplug notification user space |
368 | scripts. |
369 | |
370 | #!/bin/bash |
371 | # $Id: cpu.agent |
372 | # Kernel hotplug params include: |
373 | #ACTION=%s [online or offline] |
374 | #DEVPATH=%s |
375 | # |
376 | cd /etc/hotplug |
377 | . ./hotplug.functions |
378 | |
379 | case $ACTION in |
380 | online) |
381 | echo `date` ":cpu.agent" add cpu >> /tmp/hotplug.txt |
382 | ;; |
383 | offline) |
384 | echo `date` ":cpu.agent" remove cpu >>/tmp/hotplug.txt |
385 | ;; |
386 | *) |
387 | debug_mesg CPU $ACTION event not supported |
388 | exit 1 |
389 | ;; |
390 | esac |
391 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9