Laptop users rely on software suspension when closing the lid on their laptop, allowing the entire system to go to sleep, providing the ability to then open the lid waking the computer back up exactly as it was. The general idea is to take a snapshot of the current state of the computer's memory, and save this image to disk, an image that can later be restored back into the computer's memory. The software that accomplishes this task has long been known by the name "swsusp", an abbreviation of the term 'software suspend'. With the 2.0 release of this software, it is now referred to as "suspend2", which is available as patches for both the 2.4 [forum] and 2.6 [forum] stable kernels.

Nigel Cunningham posted an interesting summary of the improvements of suspend2 over the earlier swsusp imlementation:

"First of all, let me explain that although swsusp and suspend2 work at a very fundamental level in the same way, there are also some important differences. Of particular relevance to this conversation is the fact that swsusp makes what is as close to an atomic copy of the entire image to be saved as we can get and then saves it. In contrast, suspend2 saves one portion of the memory (lru pages), makes an atomic copy of the rest and then saves the atomic copy of the second part."

Nigel goes on to describe how the portion of suspend2 referred to as the "freezer" tracks the state of various processes, waiting until it can get a fully valid atomic copy of the memory. The current goal of the project is to get their efforts merged into the mainline 2.6 stable kernel. Read on for Nigel's full explanations.

From: Nigel Cunningham [email blocked]
To: Linux Kernel Mailing List [email blocked]
Subject: Suspend2 merge preparation: Rationale behind the freezer changes.
Date: 	Mon, 17 May 2004 16:49:17 +1000

Hi all.

In merging suspend2, one of the biggest changes is in the area of 
freezing activity. I'm writing this email in an effort to improve 
understanding of why I've implemented the freezer differently, and 
perhaps get some ideas as to how I could better achieve the desired results.

First of all, let me explain that although swsusp and suspend2 work at a 
very fundamental level in the same way, there are also some important 
differences. Of particular relevance to this conversation is the fact 
that swsusp makes what is as close to an atomic copy of the entire image 
to be saved as we can get and then saves it. In contrast, suspend2 saves 
one portion of the memory (lru pages), makes an atomic copy of the rest 
and then saves the atomic copy of the second part.

In order, then, for suspend2 to get the equivalent of an atomic copy of 
memory, pages must not be added to or removed from the LRU list once we 
start saving the image. (There are other issues and measures taken, but 
they're not relevant here).

One of the problems we face in achieving this goal is the fact that 
timers & timeouts can still fire during this period. These can of course 
be used to start new processes and to cause others (eg sleep) to exit, 
with the result that we can end up with changes to the LRU lists and 
therefore an inconsistent image.

Secondly, we have a more basic problem with the existing freezer 
implementation. A fundamental assumption made by it is that the order in 
which processes are signalled does not matter; that there will be no 
deadlocks caused by freezing one process before another. This simply 
isn't true.

Thirdly, the existing implementation does not allow us to quickly stop 
activity. Under heavy load, particularly heavy I/O (assuming the freezer 
does work), it make take quite a while for processes to respond to the 
pseudo-signal and enter the refrigerator. New processes may also be 
spawned, further complicating matters. The busier the system is, the 
more hit-and-miss freezing becomes.

The implementation of the freezer that I have developed addresses these 
concerns by adding an atomic count of the number of procesess in 
critical paths. The first part of the freezer simply waits for the 
number of processes in critical paths to reach zero.

A critical path is defined as one in which a process takes locks or 
carries out other activities which could deadlock with another process 
or make the process not respond to a freezer signal. When a process 
enters a critical path, the ACTIVITY_START macro causes it to be marked 
PF_FRIDGE_WAIT and the count of processes in critical paths is 
atomically imcremented. When it returns, a matching ACTIVITY_END macro 
reverses these effects. Use of a local variable makes it safe for 
processes to pass through multiple ACTIVITY_START calls; only the 
matching ACTIVITY_END will reverse the initial ACTIVITY_START. It may be 
that in the middle of a critical patch, there is sleeping in which we 
could safely suspend. This can be indicated by surrounding the sleep 
with ACTIVITY_PAUSING and ACTIVITY_RESTARTING calls. The thread is thus 
temporarily marked as safely suspendable.

These four macros play a further role. When we begin to wait for the 
activity counter to reach zero, a flag is set to record this fact. Macro 
calls check this flag, and a process reaching a START or RESTARTING 
activity macro while the flag is set will be refrigerated at that point 
until after the suspend cycle is completed. This helps us quiesce the 
system more quickly.

Some processes receive special treatment during this period.

A process marked PF_NOFREEZE is never refrigerated or counted in 
measuring activity.

A process may instead be marked PF_SYNCTHREAD. It is good for us to sync 
all dirty data to disc prior to suspending, just-in-case something goes 
wrong or the user uses noresume. By doing this, we maximise the 
filesystem integrity as far as is possible. PF_SYNCTHREAD is used for 
processes such as journalling threads that are used in doing this, and 
for processes which begin a filesystem sync. These processes are allowed 
to continue operation during the initial phase, and are frozen later.

The freezing process is thus:

1) Set FREEZE_NEW_ACTIVITY flag and wait for activity count to reach 
zero. New activity is held, existing activity completes critical paths 
or pauses at a safe place and syncing runs to completion.
2) Do our own sys_sync, just in case none were already running.
3) Set FREEZE_UNREFRIGERATED flag. Syncthreads will now enter the 
refrigerator of their own accord or by being signalled.
4) Signal remaining processes to be frozen. Deadlocking is avoided 
because those that would start critical paths are held at the 
ACTIVITY_START/RESTARTING calls, prior to taking the locks that would 
cause the deadlocks.

Regards,

Nigel
-- 
Nigel & Michelle Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6254 0216 (home)

Evolution (n): A hypothetical process whereby infinitely improbable 
events occur
with alarming frequency, order arises from chaos, and no one is given 
credit.



From: Pavel Machek [email blocked]
Subject: swsusp documentation updates
Date: 	Wed, 5 May 2004 11:47:19 +0200

Hi!

I'd like this to be included. People ask question I should have
answered in the documentation.
							Pavel

--- clean/Documentation/power/swsusp.txt	2004-02-05 01:53:53.000000000 +0100
+++ linux/Documentation/power/swsusp.txt	2004-05-04 23:36:26.000000000 +0200
@@ -123,10 +123,61 @@
 replace ethernet card, resume. If you are fast your users will not
 even see broken connections.
 
-Any other idea you might have tell me!
+Q: Maybe I'm missing something, but why doesn't the regular io paths
+work?
 
-Contacting the author
-If you have any question or any patch that solves the above or detected
-problems please contact me at [email blocked]. I might delay
-answering, sorry about that.
+A: (Basically) you want to replace all kernel data with kernel data saved
+on disk. How do you do that using normal i/o paths? If you'll read
+"new" data 4KB at a time, you'll crash... because you still need "old"
+data to do the reading, and "new" data may fit on same physical spot
+in memory.
 
+There are two solutions to this:
+
+* require half of memory to be free during suspend. That way you can
+read "new" data onto free spots, then cli and copy
+
+* assume we had special "polling" ide driver that only uses memory
+between 0-640KB. That way, I'd have to make sure that 0-640KB is free
+during suspending, but otherwise it would work...
+
+Q: Does linux support ACPI S4?
+
+A: No.
+
+When swsusp was created, ACPI was not too widespread, so we tried to
+avoid using ACPI-specific stuff. ACPI also is/was notoriously
+buggy. These days swsusp works on APM-only i386 machines and even
+without any power managment at all. Some versions also work on PPC.
+
+That means that machine does not enter S4 on suspend-to-disk, but
+simply enters S5. That has few advantages, you can for example boot
+windows on next boot, and return to your Linux session later. You
+could even have few different Linuxes on your box (not sharing any
+partitions), and switch between them.
+
+It also has disadvantages. On HP nx5000, if you unplug power cord
+while machine is suspended-to-disk, Linux will fail to notice that.
+
+Q: My machine doesn't work with ACPI. How can I use swsusp than ?
+
+A: Do reboot() syscall with right parameters. Warning: glibc gets in
+its way, so check with strace:
+ 
+reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, 0xd000fce2)
+
+(Thanks to Peter Osterlund:)
+
+#include <unistd.h>
+#include <syscall.h>
+
+#define LINUX_REBOOT_MAGIC1     0xfee1dead
+#define LINUX_REBOOT_MAGIC2     672274793
+#define LINUX_REBOOT_CMD_SW_SUSPEND     0xD000FCE2
+
+int main()
+{
+    syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
+            LINUX_REBOOT_CMD_SW_SUSPEND, 0);
+    return 0;
+}

-- 
934a471f20d6580d5aad759bf0d97ddc



From: Nigel Cunningham [email blocked]
Subject: Re: swsusp documentation updates
Date: 	Wed, 05 May 2004 19:55:07 +1000

Howdy.

On Wed, 2004-05-05 at 19:47, Pavel Machek wrote:
> +There are two solutions to this:
> +
> +* require half of memory to be free during suspend. That way you can
> +read "new" data onto free spots, then cli and copy

Would you consider adding:

(Suspend2, which allows more than half of memory to be saved, is a
variant on this).

Regards,

Nigel
-- 
Nigel & Michelle Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6254 0216 (home)

Evolution (n): A hypothetical process whereby infinitely improbable events occur 
with alarming frequency, order arises from chaos, and no one is given credit.



From: Pavel Machek [email blocked]
Subject: Re: swsusp documentation updates
Date: 	Wed, 5 May 2004 12:11:58 +0200

Hi!

> 
> Would you consider adding:
> 
> (Suspend2, which allows more than half of memory to be saved, is a
> variant on this).

How would you like this added?

swsusp2 shares this fundamental limitation, but does not include user
data and disk caches into "used memory" by saving them in
advance. That means that limitation goes away in practice.

And perhaps you want to write "What is swsusp2?" question/answer?

								Pavel
-- 
934a471f20d6580d5aad759bf0d97ddc



From: Nigel Cunningham [email blocked]
Subject: Re: swsusp documentation updates
Date: 	Thu, 06 May 2004 07:03:28 +1000

Howdy.

On Wed, 2004-05-05 at 20:11, Pavel Machek wrote:
> 
> How would you like this added?

Well, I was thinking of simply adding the above in brackets on the same
or the next line.

> swsusp2 shares this fundamental limitation, but does not include user
> data and disk caches into "used memory" by saving them in
> advance. That means that limitation goes away in practice.
> 
> And perhaps you want to write "What is swsusp2?" question/answer?

I'm avoiding calling it swsusp2 because 'swsusp' is unpronouncable. It
also gets different interpretations: suspend2 isn't 'swap suspend'
because it's not inherently limited to saving to swap. 'software
suspend' is too long and doesn't seem to occur as quickly. Thus I'm
simply using suspend2.

Regards,

Nigel
-- 
Nigel & Michelle Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6254 0216 (home)

Evolution (n): A hypothetical process whereby infinitely improbable events occur 
with alarming frequency, order arises from chaos, and no one is given credit.



From: Nigel Cunningham [email blocked]
Subject: Re: swsusp documentation updates
Date: 	Thu, 06 May 2004 09:10:26 +1000

Hi.

On Wed, 2004-05-05 at 20:11, Pavel Machek wrote:
> 
> How would you like this added?
> 
> swsusp2 shares this fundamental limitation, but does not include user
> data and disk caches into "used memory" by saving them in
> advance. That means that limitation goes away in practice.

That sounds good. I'd include that.

> And perhaps you want to write "What is swsusp2?" question/answer?

How does this sound?...

What is 'swsusp2'?

swsusp2 is Software Suspend 2, forked implementation of suspend-to-disk
which is available as separate patches for 2.4 and 2.6 kernels from
swsusp.sourceforge.net. It includes support for SMP, 4GB Highmem and
preemption. It also has a extensible architecture that allows for
arbitrary transformations on the image (compression, encryption) and
arbitrary backends for writing the image (eg to swap or an NFS
share[Work In Progress]). Questions regarding suspend2 should be sent to
the mailing list available through the Suspend2 website, and not to the
Linux Kernel Mailing List. We are working toward merging Suspend2 into
the mainline kernel.
-- 
Nigel & Michelle Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6254 0216 (home)

Evolution (n): A hypothetical process whereby infinitely improbable events occur 
with alarming frequency, order arises from chaos, and no one is given credit.



From: Pavel Machek [email blocked]
Subject: Re: swsusp documentation updates
Date: 	Tue, 11 May 2004 04:51:57 +0200

Hi!

> > And perhaps you want to write "What is swsusp2?" question/answer?
> 
> How does this sound?...
> 
> What is 'swsusp2'?
> 
> swsusp2 is Software Suspend 2, forked implementation of suspend-to-disk
> which is available as separate patches for 2.4 and 2.6 kernels from
> swsusp.sourceforge.net. It includes support for SMP, 4GB Highmem and
> preemption. It also has a extensible architecture that allows for
> arbitrary transformations on the image (compression, encryption) and
> arbitrary backends for writing the image (eg to swap or an NFS
> share[Work In Progress]). Questions regarding suspend2 should be sent to
> the mailing list available through the Suspend2 website, and not to the
> Linux Kernel Mailing List. We are working toward merging Suspend2 into
> the mainline kernel.

You are using swsusp2, suspend2 and Suspend2. I figured out you mean
suspend2 and applied this: (it will eventually propagate).
								Pavel

Q: What is 'suspend2'?

A: suspend2 is 'Software Suspend 2', forked implementation of
suspend-to-disk which is available as separate patches for 2.4 and 2.6
kernels from swsusp.sourceforge.net. It includes support for SMP, 4GB
highmem and preemption. It also has a extensible architecture that
allows for arbitrary transformations on the image (compression,
encryption) and arbitrary backends for writing the image (eg to swap
or an NFS share[Work In Progress]). Questions regarding suspend2
should be sent to the mailing list available through the suspend2
website, and not to the Linux Kernel Mailing List. We are working
toward merging suspend2 into the mainline kernel.


-- 
When do you have heart between your knees?



From: Nigel Cunningham [email blocked]
Subject: Re: swsusp documentation updates
Date: 	Wed, 12 May 2004 08:45:26 +1000

Hi.

On Tue, 11 May 2004 12:51, Pavel Machek wrote:
> You are using swsusp2, suspend2 and Suspend2. I figured out you mean
> suspend2 and applied this: (it will eventually propagate).
> 								Pavel

Sorry. Yes, I did mean suspend2. Thanks!

Nigel

• Archive of above thread