Messages in this thread | | | Date | Tue, 16 Mar 2004 16:10:05 +0100 | From | Pavel Machek <> | Subject | Re: [Swsusp-devel] Re: The verdict on the future of suspending to disk? |
| |
Hi!
> 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?
It should suspend at any load, but AFAICR those hooks are not for that. They are neccessary for "crashed nfs server case", which kill -SIGSTOP does not handle. (IMNSHO thats bug in -SIGSTOP and pretty orthogonal to swsusp).
> 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
There's even more important goal. I'd call it
O. Do not impair system reliablity *when swsusp is not in use*. Do not make further development of system harder by putting too much hooks into other code.
> 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.
I still do not believe 1. and 2. *require* that ugly hooks (as long as your NFS server is up).
Now, what if NFS server is down? I'd not handle it for now; if your harddrive stops working you can't suspend, too, and NFS is too similar to disk.
> 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! > :-)
For first merge, I'd like to have simplest possible version, that's no compression, powerdown at the end, no escape.
> 4. Requires PM fixes and driver level intrusion, can be worked around by > killing apps and unloading drivers. Eventually this has to be fixed.
Yes. People are working on that. Pavel -- Horseback riding is like software... ...vgf orggre jura vgf serr. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |