Lines Matching +full:suspend +full:- +full:to +full:- +full:ram
2 Interaction of Suspend code (S3) with the CPU hotplug infrastructure
5 (C) 2011 - 2014 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
8 I. Differences between CPU hotplug and Suspend-to-RAM
11 How does the regular CPU hotplug code differ from how the Suspend-to-RAM
14 Well, a picture is worth a thousand words... So ASCII art follows :-)
17 interactions involving the freezer and CPU hotplug and also tries to explain
21 What happens when regular CPU hotplug and Suspend-to-RAM race with each other
24 On a high level, the suspend-resume cycle goes like this::
26 |Freeze| -> |Disable nonboot| -> |Do suspend| -> |Enable nonboot| -> |Thaw |
32 Suspend call path
33 -----------------
35 Write 'mem' to
62 | ----------
76 frozen_cpus mask ----------
89 Do suspend
109 It is to be noted here that the system_transition_mutex lock is acquired at the
110 very beginning, when we are just starting out to suspend, and then released only
111 after the entire cycle is complete (i.e., suspend + resume).
118 -----------------------------
120 Write 0 (or 1) to
154 regular CPU hotplug and the suspend code path converge at the _cpu_down() and
155 _cpu_up() functions. They differ in the arguments passed to these functions,
157 argument. But during suspend, since the tasks are already frozen by the time
158 the non-boot CPUs are offlined or onlined, the _cpu_*() functions are called
159 with the 'tasks_frozen' argument set to 1.
164 -------------------------------------------
166 - kernel/power/process.c : freeze_processes(), thaw_processes()
167 - kernel/power/suspend.c : suspend_prepare(), suspend_enter(), suspend_finish()
168 - kernel/cpu.c: cpu_[up|down](), _cpu_[up|down](),
174 ------------------------------------------------
187 to apply the same microcode revision to each of the CPUs.
188 To give an example of x86, the collect_cpu_info() function defined in
190 and thereby in applying the correct microcode revision to it.
192 all CPUs, in order to handle case 'b' described below.
197 In this case since we probably need to apply different microcode revisions
198 to different CPUs, the kernel maintains a copy of the correct microcode
203 c. When a CPU is physically hot-unplugged and a new (and possibly different
204 type of) CPU is hot-plugged into the system:
222 discovery is performed and the right microcode is applied to the CPU after
226 d. Handling microcode update during suspend/hibernate:
230 off during a CPU offline. They are just put to the lowest C-states possible.
231 Hence, in such a case, it is not really necessary to re-apply microcode
235 This is the usual scenario encountered during a resume after a suspend.
237 powered off, during restore it becomes necessary to apply the microcode
238 images to all the CPUs.
240 [Note that we don't expect someone to physically pull out nodes and insert
241 nodes with a different type of CPUs in-between a suspend-resume or a
245 as part of the suspend/hibernate cycle (cpuhp_tasks_frozen is set),
249 CPUs, it just applies them to the CPUs, avoiding any re-discovery of CPU
251 right for the CPUs or not (due to the above assumption that physical CPU
252 hotplug will not be done in-between suspend/resume or hibernate/restore
259 Are there any known problems when regular CPU hotplug and suspend race
264 1. When invoking regular CPU hotplug, the 'tasks_frozen' argument passed to
267 tasks could have been frozen by an out-of-band event such as a suspend
272 2. If a regular CPU hotplug stress test happens to race with the freezer due
273 to a suspend operation in progress at the same time, then we could hit the
278 * Then freezer gets to work and freezes userspace.
281 TASK_UNINTERRUPTIBLE state, in order to get the microcode image.
282 * Now the freezer continues and tries to freeze the remaining tasks. But
283 due to this wait mentioned above, the freezer won't be able to freeze
286 As a result of this task freezing failure, the suspend operation gets