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

[Nigel Cunningham]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/