Messages in this thread | | | Subject | Re: [Swsusp-devel] Re: The verdict on the future of suspending to disk? | From | Nigel Cunningham <> | Date | Wed, 17 Mar 2004 09:28:32 +1300 |
| |
Hi.
On Wed, 2004-03-17 at 04:10, Pavel Machek wrote: > 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).
The NFS example was just one example; they are intended for 'suspend at any load'. Actually, I should say, they're intended for 'suspend first time at any load'. Maybe I should go back into the mailing list logs from around the time when we made the change, to see again the kind of issues we were attacking.
> 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.
I believe we achieve that. All the hooks do is atomically adjust a counter of the number of busy processes, adjust process flags (in the case of processes running sync), and check that we're not trying to suspend. None of those things should affect reliability, and months of testing by many users has not given any indication that they do.
> > 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.
Not arguing there. I either want to merge the whole lot at once (unlikely, I know), or in discrete patches. I'm sure there must be some bugs left somewhere that people will spot.
Nigel -- Nigel Cunningham C/- Westminster Presbyterian Church Belconnen 61 Templeton Street, Cook, ACT 2614. +61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur with alarming frequency, order arises from chaos, and no one is given credit.
- 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/
| |