The verdict on the future of suspending to disk?

The verdict on the future of suspending to disk?

[Nigel Cunningham]

Hi.

Just wanting clarification; what are we thinking about the future of
suspend implementations? Let me throw my current
understanding/suggestion in for starters:

- Drop PM_DISK?
- Apply patches making swsusp into suspend2, leaving out freezer changes
until people are convinced the current solution is insufficient.
- Pavel keeps maintaining the end result? (I'm happy to maintain it if
he wants; I'm assuming when I say this he'll still be dealing with S3
and Patrick will be deal with PM support proper).

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.

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

[Karol Kozimor]

Thus wrote Nigel Cunningham:
> - Pavel keeps maintaining the end result? (I'm happy to maintain it if
> he wants; I'm assuming when I say this he'll still be dealing with S3
> and Patrick will be deal with PM support proper).

Patrick has been silent for months, which apart from further complicating
matters makes any assumptions not quite right :)
Best regards

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: The verdict on the future of suspending to disk?

[Pavel Machek]

Hi!

> Just wanting clarification; what are we thinking about the future of
> suspend implementations? Let me throw my current
> understanding/suggestion in for starters:

I'd like to know the results, too.

> - Drop PM_DISK?

I do not care which one is dropped as long as only one implementation
remains. Droping PM_DISK is indeed easiest as noone touched it for
half a year.

> - Apply patches making swsusp into suspend2, leaving out freezer changes
> until people are convinced the current solution is insufficient.

Could you prepare some "swsusp2 without freezer" patch, so that we can
see how it looks like? 

> - Pavel keeps maintaining the end result? (I'm happy to maintain it if
> he wants; I'm assuming when I say this he'll still be dealing with S3
> and Patrick will be deal with PM support proper).

I do not think Patrick is going to maintain anything.

If you want to maintain it, you can have it. Big plus if you are able
to deal with Patrick.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: The verdict on the future of suspending to disk?

[Pavel Machek]

Hi!

> > - Apply patches making swsusp into suspend2, leaving out freezer changes
> > until people are convinced the current solution is insufficient.
> 
> Could you prepare some "swsusp2 without freezer" patch, so that we can
> see how it looks like? 

Or.. if you prefer. Would it be possible to get "two stage
refrigerator but without intrusive changes"? That should still be
better than what is there just now, and it should be mostly
independend change (right?). It will not give us suspend when nfs
server dies, but at least it will not have problems with mysqld...

								Pavel-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

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

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

[Pavel Machek]

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.

Re: The verdict on the future of suspending to disk?

[Nigel Cunningham]

Hi.

On Wed, 2004-03-17 at 00:37, Pavel Machek wrote:
> I do not think Patrick is going to maintain anything.
> 
> If you want to maintain it, you can have it. Big plus if you are able
> to deal with Patrick.

Okay, but can we clearly delineate responsibilities? I'm happy to deal
with the suspend-to-disk stuff because I understand it. I don't however
understand suspend-to-ram or kobjects (yes, I will need to learn them)
or device drivers, so I don't want anyone thinking I'm going to
concentrate on anything more than what I'm already doing. That said, I'd
love to take over software suspend and work on merging the work I've
done.

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.

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

[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.