Lines Matching refs:we

17 we only consider hibernation, but the description also applies to suspend).
28 it loop until PF_FROZEN is cleared for it. Then, we say that the task is
75   - freezes all tasks (including kernel threads) because we can't freeze
79   - thaws only kernel threads; this is particularly useful if we need to do
81     userspace tasks, or if we want to postpone the thawing of userspace tasks
84   - thaws all tasks (including kernel threads) because we can't thaw userspace
95 IV. Why do we do that?
100 hibernation.  At the moment we have no simple means of checkpointing
102 metadata on disks, we cannot bring them back to the state from before the
113 2. Next, to create the hibernation image we need to free a sufficient amount of
114 memory (approximately 50% of available RAM) and we need to do that before
115 devices are deactivated, because we generally need them for swapping out.  Then,
116 after the memory for the image has been freed, we don't want tasks to allocate
117 additional memory and we prevent them from doing that by freezing them earlier.
124 process running on a second CPU while we are suspending devices may, for
125 example, be troublesome and without the freezing of tasks we would need some
131 "RJW:> Why we freeze tasks at all or why we freeze kernel threads?
135 I _do_ realize the IO request queue issues, and that we cannot actually do
136 s2ram with some devices in the middle of a DMA.  So we want to be able to
158 that depends on all CPUs being online while it's running.  Since we need to
176 2. Now that we have FUSE, plus the framework for doing device drivers in
182 other one is more serious, but it seems that we can work around it by using
183 hibernation (and suspend) notifiers (in that case, though, we won't be able to