Re: [Swsusp-devel] Re: The verdict on the future of suspending to disk?

["Michael Frank" <mhf@linuxmail.org>]

Without reliability and being able to suspend at any load
(when the batteries/UPS go flat)  software suspend is all
but useless.  What for suspend if it does not resume and
eats work left in RAM?

Common users objectives for a software suspend mechanism are:

1. To not impair system reliability. It must run without crash
       and reboots between kernel upgrades.
       100 cycles in 2 hours is a quickie
       1000 cycles in a day are a short test
       xxxx cycles in a month are a life test

2. To handle any cpu and io load
	10+ concurrent unixbenchs, 4 concurrent dd loops, nfs and ssh
       cross accesses, Load avg 20-40, cs of 100,000, 20MB io
       sustained for days at a cycle a minute... No freezing failures

3. To support the spectrum of user requirements wrt functionality
	for portable, desktop, and embedded apps

4. To handle driver suspend and resume at any time. Apps should not
       have to be terminated.

Swsusp2 meets 1. and 2. and many of 3. Swsusp2 is also modular and can be
expanded to add things like NFS suspend/resume.

1. and 2. require a sophisticated freezing mechanism and kernel level
"intrusion". Most of this "intrusion" is simetrical and easily understood.
This is what UGLY macros are for.

3. Can be argued about: Compression or no compression, reboot functionality
    for multi boot or not, Escape or no Escape (I need it every day) -
    If you ever would dare to suspend you would want an Escape function too! :-)

4. Requires PM fixes and driver level intrusion, can be worked around by
    killing apps and unloading drivers. Eventually this has to be fixed.

Regards
Michael