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

[Michael Frank]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/