Suspend2 - Request for review & inclusion in -mm

Suspend2 - Request for review & inclusion in -mm

[Nigel Cunningham]

Hi all.

I'd like, at long last, to submit Suspend2 for review and inclusion in -mm.

All going well, I'll shortly be sending a number of sets of patches, which 
together represent the whole of suspend2 as it stands at the moment. Those of 
you who've looked at Suspend2 code before will see that there are far fewer 
changes outside of kernel/power than there have been in the past. In some 
cases, this is because we were early adopters of some functionality that has 
now been merged, and in others because better, less intrusive ways have been 
found of doing some things.

Some of the advantages of suspend2 over swsusp and uswsusp are:

- Speed (Asynchronous I/O and readahead for synchronous I/O)
- Well tested in a wide range of configurations
- Supports multiple swap partitions and files
- Supports writing to ordinary files and raw devices.
- Userspace helpers for user interface and storage management.
- Support for cancelling the suspend at any point while the image is being 
written (can be disabled)
- Can be configured and reconfigured without rebooting.
- Scripting support

I'm very much part-time on this, so please accept my apologies in advance if 
I'm slow in replying to responses.

A git tree is now available on kernel.org:

http://www.kernel.org/git/?p=linux/kernel/git/nigelc/suspend2-2.6.git;a=summary

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

Re: Suspend2 - Request for review & inclusion in -mm

[Pavel Machek]

Hi!

> I'd like, at long last, to submit Suspend2 for review and inclusion in -mm.
> 
> All going well, I'll shortly be sending a number of sets of patches, which 
> together represent the whole of suspend2 as it stands at the moment. Those of 
> you who've looked at Suspend2 code before will see that there are far fewer 
> changes outside of kernel/power than there have been in the past. In some 
> cases, this is because we were early adopters of some functionality that has 
> now been merged, and in others because better, less intrusive ways have been 
> found of doing some things.
> 
> Some of the advantages of suspend2 over swsusp and uswsusp are:
> 
> - Speed (Asynchronous I/O and readahead for synchronous I/O)

uswsusp should be able to match suspend2's speed. It can do async I/O,
etc...

> - Well tested in a wide range of configurations
> - Supports multiple swap partitions and files

Doable in userspace with uswsusp.

> - Supports writing to ordinary files and raw devices.

Should be doable in userspace with uswsusp, too; I actually had raw
devices version at one point.

> - Userspace helpers for user interface and storage management.

Better put it completely in userspace :-).

> - Support for cancelling the suspend at any point while the image is being 
> written (can be disabled)

uswsusp does that... or did that at some point.

> - Can be configured and reconfigured without rebooting.

No problem for uswsusp.

> - Scripting support

What does that mean?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[Brad Campbell]

Pavel Machek wrote:
>> Some of the advantages of suspend2 over swsusp and uswsusp are:
>>
>> - Speed (Asynchronous I/O and readahead for synchronous I/O)
> 
> uswsusp should be able to match suspend2's speed. It can do async I/O,
> etc...

ARGH!

And the next version of windows will have all the wonderful features that MacOSX has now so best not 
upgrade to Mac as you can just wait for the next version of windows.

suspend2 has it *now*. It works, it's stable.

uswsusp is a great idea, really.. I love it.. but suspend2 is here, it works, it's stable and it's 
now. Why continue to deprive the mainstream of these features because "uswsusp should".. as yet it 
doesn't.. and when it does then we can phase out the currently stable, working alternative that has 
all these features that uswsusp _will_ have, after it's had them for a year or so and its been 
proven stable. Not only that, I'll be happy to migrate over to it. Until then however, you can pry 
suspend2.. cold, dead.. blah blah..

Honestly, I have given up worrying if it's in-kernel or not. Nigel makes it so easy to apply the 
patches to the current kernels it's a doddle in any case, however I'm sure it would be much easier 
on everyone if it were in the tree.

Brad (suspend user since 2.2.17 - and suspend2 is a heck of a lot more reliable/usable than the 
in-kernel version ever has been for me)
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[Andreas Mohr]

Hi,

On Tue, Jun 27, 2006 at 07:22:37PM +0400, Brad Campbell wrote:
> Pavel Machek wrote:
> >>Some of the advantages of suspend2 over swsusp and uswsusp are:
> >>
> >>- Speed (Asynchronous I/O and readahead for synchronous I/O)
> >
> >uswsusp should be able to match suspend2's speed. It can do async I/O,
> >etc...
> 
> ARGH!
> 
> And the next version of windows will have all the wonderful features that 
> MacOSX has now so best not upgrade to Mac as you can just wait for the 
> next version of windows.
> 
> suspend2 has it *now*. It works, it's stable.

I have to admit that this posting has touched a nerve.

> Brad (suspend user since 2.2.17 - and suspend2 is a heck of a lot more 
> reliable/usable than the in-kernel version ever has been for me)

I've also been a suspend user in the very early 2.2.x days (where it actually
worked pretty well for its early development stage).

However since it's always been a hassle to apply extra patches which then
never worked fully sufficiently without a lot of fiddling (which is not
really completely the fault of the swsusp code due to very incomplete
driver support, though) I've almost completely given up on it and don't
even run it any more on any of my machines currently.

> uswsusp is a great idea, really.. I love it.. but suspend2 is here, it 
> works, it's stable and it's now. Why continue to deprive the mainstream of 
> these features because "uswsusp should".. as yet it doesn't.. and when it 
> does then we can phase out the currently stable, working alternative that 
> has all these features that uswsusp _will_ have, after it's had them for a 
> year or so and its been proven stable. Not only that, I'll be happy to 
> migrate over to it. Until then however, you can pry suspend2.. cold, 
> dead.. blah blah..

Given the above explanation, it's obvious that I'm an outside watcher now,
but if swsusp2 success rate is clearly higher than the standard version,
then I'd also strongly advocate this direction since, quite frankly,
I'm sick and tired of waiting for suspend-to-disk software functionality.
It's been 6(*SIX*!) years already since a development version worked
quite well for me with >> 30 cycles until a crash, and I'm afraid that
since then on several PCs in the many years in between it was almost always
a miss rather than a hit.

Suspend/resume is an incredibly problematic area (any single mis-behaving
driver can kill it), we've been missing it for far too long already,
and if the swsusp2 codebase currently works much better than alternatives
(in this area we need as much reliability and thus success rate as possible)
then IMHO it's more than high time to get something of that in-kernel.

We can get things into perfection later IMHO, given that development
has taken that extremely long already.

Finally, I'm sure you're all doing wonderful work, but let's try to find
a solution that finally works for most people (I'm sure many people would
be extremely interested to have this working by default with >= 80%
reliability on an average desktop box).

Andreas Mohr

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[Avuton Olrich]

On 6/27/06, Andreas Mohr <andi@rhlx01.fht-esslingen.de> wrote:
> Hi,
>
> On Tue, Jun 27, 2006 at 07:22:37PM +0400, Brad Campbell wrote:
> > Pavel Machek wrote:
> > >>Some of the advantages of suspend2 over swsusp and uswsusp are:
> > >>
> > >>- Speed (Asynchronous I/O and readahead for synchronous I/O)
> > >
> > >uswsusp should be able to match suspend2's speed. It can do async I/O,
> > >etc...
> >
> > ARGH!
> >
> > And the next version of windows will have all the wonderful features that
> > MacOSX has now so best not upgrade to Mac as you can just wait for the
> > next version of windows.
> >
> > suspend2 has it *now*. It works, it's stable.

I'm not sure it's a reason for it to go in, but the truth is suspend2
does work in more cases, ime. uswsusp is alpha(?) swsusp doesn't work
(for me in most cases), suspend-to-ram doesn't work (probably even
less cases than swsusp), suspend2 works. It's working status for more
of the userbase should (hopefully) be a concideration.
-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[dirk husemann]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]

Brad Campbell wrote:
> Pavel Machek wrote:
>>> Some of the advantages of suspend2 over swsusp and uswsusp are:
>>>
>>> - Speed (Asynchronous I/O and readahead for synchronous I/O)
>>
>> uswsusp should be able to match suspend2's speed. It can do async I/O,
>> etc...
>
> ARGH!
>
> And the next version of windows will have all the wonderful features
> that MacOSX has now so best not upgrade to Mac as you can just wait
> for the next version of windows.
>
> suspend2 has it *now*. It works, it's stable.
exactly my sentiments!! IT JUST WORKS! NOW!
>
> uswsusp is a great idea, really.. I love it.. but suspend2 is here, it
> works, it's stable and it's now. Why continue to deprive the
> mainstream of these features because "uswsusp should".. as yet it
> doesn't..
<soapbox>
and i'm sick and tired of waiting for the pot of suspend gold at the end
of the kernel rainbow that will eventually be available...could we
include suspend2 now while the world waits with bated breath for uswsusp
to emerge?
</soapbox>


-- 
Dr Dirk Husemann, Pervasive Computing, IBM Research, Zurich Research Lab
	hud@zurich.ibm.com --- http://www.zurich.ibm.com/~hud/
       PGP key: http://www.zurich.ibm.com/~hud/contact/PGP
  PGP Fingerprint: 983C 48E7 0A78 A313 401C  C4AD 3C0A 278E 6431 A149
	     Email only authentic if signed with PGP key.

Appended to this email is an electronic signature attachment. You can
ignore it if your email program does not know how to verify such a
signature. If you'd like to learn more about this topic, www.gnupg.org
is a good starting point.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[Pavel Machek]

On Tue 2006-06-27 19:22:37, Brad Campbell wrote:
> Pavel Machek wrote:
> >>Some of the advantages of suspend2 over swsusp and uswsusp are:
> >>
> >>- Speed (Asynchronous I/O and readahead for synchronous I/O)
> >
> >uswsusp should be able to match suspend2's speed. It can do async I/O,
> >etc...
> 
> ARGH!
> 
> And the next version of windows will have all the wonderful features that 
> MacOSX has now so best not upgrade to Mac as you can just wait for the next 
> version of windows.
> 
> suspend2 has it *now*. It works, it's stable.

uswsusp also has it *now*, in case you missed it. I just do not do
benchmark runs all the time, and don't know how fast suspend2
is. uswsusp already uses normal I/O ... and that is asynchronous.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[Dave Jones]

On Tue, Jun 27, 2006 at 09:03:24PM +0200, Pavel Machek wrote:

 > uswsusp already uses normal I/O ... and that is asynchronous.

Errm, no. it isn't.

		Dave

-- 
http://www.codemonkey.org.uk

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[Pavel Machek]

On Tue 2006-06-27 15:19:03, Dave Jones wrote:
> On Tue, Jun 27, 2006 at 09:03:24PM +0200, Pavel Machek wrote:
> 
>  > uswsusp already uses normal I/O ... and that is asynchronous.
> 
> Errm, no. it isn't.

Okay...

It is asynchronous on the write part. On the read part, it is not, but
that should be okay... readahead should save us.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Pavel Machek]

Hi!

> > uswsusp is a great idea, really.. I love it.. but suspend2 is here, it 
> > works, it's stable and it's now. Why continue to deprive the mainstream of 
> > these features because "uswsusp should".. as yet it doesn't.. and when it 
> > does then we can phase out the currently stable, working alternative that 
> > has all these features that uswsusp _will_ have, after it's had them for a 
> > year or so and its been proven stable. Not only that, I'll be happy to 
> > migrate over to it. Until then however, you can pry suspend2.. cold, 
> > dead.. blah blah..
> 
> Given the above explanation, it's obvious that I'm an outside watcher now,
> but if swsusp2 success rate is clearly higher than the standard version,
> then I'd also strongly advocate this direction since, quite frankly,

I do not think suspend2 works on more machines than in-kernel
swsusp. Problems are in drivers, and drivers are shared.

That means that if you have machine where suspend2 works and swsusp
does not, please tell me. I do not think there are many of them.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[Pavel Machek]

On Tue 2006-06-27 09:01:33, Avuton Olrich wrote:
> On 6/27/06, Andreas Mohr <andi@rhlx01.fht-esslingen.de> wrote:
> >Hi,
> >
> >On Tue, Jun 27, 2006 at 07:22:37PM +0400, Brad Campbell wrote:
> >> Pavel Machek wrote:
> >> >>Some of the advantages of suspend2 over swsusp and uswsusp are:
> >> >>
> >> >>- Speed (Asynchronous I/O and readahead for synchronous I/O)
> >> >
> >> >uswsusp should be able to match suspend2's speed. It can do async I/O,
> >> >etc...
> >>
> >> ARGH!
> >>
> >> And the next version of windows will have all the wonderful features that
> >> MacOSX has now so best not upgrade to Mac as you can just wait for the
> >> next version of windows.
> >>
> >> suspend2 has it *now*. It works, it's stable.
> 
> I'm not sure it's a reason for it to go in, but the truth is suspend2
> does work in more cases, ime. uswsusp is alpha(?) swsusp doesn't work
> (for me in most cases), suspend-to-ram doesn't work (probably even
> less cases than swsusp), suspend2 works. It's working status for more
> of the userbase should (hopefully) be a concideration.

When swsusp does not work, there's no point trying uswsusp. It is
mostly same code.

suspend-to-ram is a very different animal.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Sebastian Kügler]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

On Wednesday 28 June 2006 00:22, Pavel Machek wrote:
> > > uswsusp is a great idea, really.. I love it.. but suspend2 is here, it
> > > works, it's stable and it's now. Why continue to deprive the mainstream
> > > of these features because "uswsusp should".. as yet it doesn't.. and
> > > when it does then we can phase out the currently stable, working
> > > alternative that has all these features that uswsusp _will_ have, after
> > > it's had them for a year or so and its been proven stable. Not only
> > > that, I'll be happy to migrate over to it. Until then however, you can
> > > pry suspend2.. cold, dead.. blah blah..
> >
> > Given the above explanation, it's obvious that I'm an outside watcher
> > now, but if swsusp2 success rate is clearly higher than the standard
> > version, then I'd also strongly advocate this direction since, quite
> > frankly,
>
> I do not think suspend2 works on more machines than in-kernel
> swsusp. Problems are in drivers, and drivers are shared.
>
> That means that if you have machine where suspend2 works and swsusp
> does not, please tell me. I do not think there are many of them.

Maybe not machines, but definitely usage scenarios. I've tried both 
implementations lately, and swsusp would often -- especially under high 
memory load -- just return from trying, while suspend2 succeeds in freeing 
enough memory to be able to suspend _every_ time. 

Returning with "sorry, not enough free mem" is definitely nothing you'd want 
when you stuff your notebook into the bag because you have to change trains, 
for example.

Is that something uswsusp is likely to change anytime soon?
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Experience, n.:   Something you don't get until just after you need it. - 
Olivier


[-- Attachment #2: Type: application/pgp-signature, Size: 483 bytes --]

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Pavel Machek]

On Wed 2006-06-28 00:38:59, Sebastian Kügler wrote:
> On Wednesday 28 June 2006 00:22, Pavel Machek wrote:
> > > > uswsusp is a great idea, really.. I love it.. but suspend2 is here, it
> > > > works, it's stable and it's now. Why continue to deprive the mainstream
> > > > of these features because "uswsusp should".. as yet it doesn't.. and
> > > > when it does then we can phase out the currently stable, working
> > > > alternative that has all these features that uswsusp _will_ have, after
> > > > it's had them for a year or so and its been proven stable. Not only
> > > > that, I'll be happy to migrate over to it. Until then however, you can
> > > > pry suspend2.. cold, dead.. blah blah..
> > >
> > > Given the above explanation, it's obvious that I'm an outside watcher
> > > now, but if swsusp2 success rate is clearly higher than the standard
> > > version, then I'd also strongly advocate this direction since, quite
> > > frankly,
> >
> > I do not think suspend2 works on more machines than in-kernel
> > swsusp. Problems are in drivers, and drivers are shared.
> >
> > That means that if you have machine where suspend2 works and swsusp
> > does not, please tell me. I do not think there are many of them.
> 
> Maybe not machines, but definitely usage scenarios. I've tried both 
> implementations lately, and swsusp would often -- especially under high 
> memory load -- just return from trying, while suspend2 succeeds in freeing 
> enough memory to be able to suspend _every_ time. 

Refrigerator fixes should help with this one. Does it still happen in
2.6.17?

> Is that something uswsusp is likely to change anytime soon?

Actually this is common code for both swsusp and uswsusp; yes this
should be fixed.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Sebastian Kügler]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

On Wednesday 28 June 2006 00:51, Pavel Machek wrote:
> On Wed 2006-06-28 00:38:59, Sebastian Kügler wrote:
> > On Wednesday 28 June 2006 00:22, Pavel Machek wrote:
> > > I do not think suspend2 works on more machines than in-kernel
> > > swsusp. Problems are in drivers, and drivers are shared.
> > >
> > > That means that if you have machine where suspend2 works and swsusp
> > > does not, please tell me. I do not think there are many of them.
> >
> > Maybe not machines, but definitely usage scenarios. I've tried both
> > implementations lately, and swsusp would often -- especially under high
> > memory load -- just return from trying, while suspend2 succeeds in
> > freeing enough memory to be able to suspend _every_ time.
>
> Refrigerator fixes should help with this one. Does it still happen in
> 2.6.17?

Last release I tested was 2.6.17-rc6-git7.

> > Is that something uswsusp is likely to change anytime soon?
>
> Actually this is common code for both swsusp and uswsusp; yes this
> should be fixed.

In the above mentioned release it definitely is not fixed.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you can't stand the heat, get out of the kitchen. - Harry S. Truman


[-- Attachment #2: Type: application/pgp-signature, Size: 483 bytes --]

Re: Suspend2 - Request for review & inclusion in -mm

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 2192 bytes --]

Hi.

On Tuesday 27 June 2006 23:33, Pavel Machek wrote:
> Hi!
>
> > I'd like, at long last, to submit Suspend2 for review and inclusion in
> > -mm.
> >
> > All going well, I'll shortly be sending a number of sets of patches,
> > which together represent the whole of suspend2 as it stands at the
> > moment. Those of you who've looked at Suspend2 code before will see that
> > there are far fewer changes outside of kernel/power than there have been
> > in the past. In some cases, this is because we were early adopters of
> > some functionality that has now been merged, and in others because
> > better, less intrusive ways have been found of doing some things.
> >
> > Some of the advantages of suspend2 over swsusp and uswsusp are:
> >
> > - Speed (Asynchronous I/O and readahead for synchronous I/O)
>
> uswsusp should be able to match suspend2's speed. It can do async I/O,
> etc...
>
> > - Well tested in a wide range of configurations
> > - Supports multiple swap partitions and files
>
> Doable in userspace with uswsusp.

Doable != done.

> > - Supports writing to ordinary files and raw devices.
>
> Should be doable in userspace with uswsusp, too; I actually had raw
> devices version at one point.
>
> > - Userspace helpers for user interface and storage management.
>
> Better put it completely in userspace :-).
>
> > - Support for cancelling the suspend at any point while the image is
> > being written (can be disabled)
>
> uswsusp does that... or did that at some point.
>
> > - Can be configured and reconfigured without rebooting.
>
> No problem for uswsusp.
>
> > - Scripting support
>
> What does that mean?

At boot time, having done anything you need to do to set up access to the 
image storage, you can:

cat /proc/suspend2/image_exists

The result shows 0 if no image exists, or 1 and a couple of extra lines of 
detail from the header if an image does exist (or -1 if there's no 
recognisable signature).

You can also echo 0 > /proc/suspend2/image_exists to invalidate an image.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[Brad Campbell]

Pavel Machek wrote:
> On Tue 2006-06-27 19:22:37, Brad Campbell wrote:
>> Pavel Machek wrote:
>>>> Some of the advantages of suspend2 over swsusp and uswsusp are:
>>>>
>>>> - Speed (Asynchronous I/O and readahead for synchronous I/O)
>>> uswsusp should be able to match suspend2's speed. It can do async I/O,
>>> etc...
>> ARGH!
>>
>> And the next version of windows will have all the wonderful features that 
>> MacOSX has now so best not upgrade to Mac as you can just wait for the next 
>> version of windows.
>>
>> suspend2 has it *now*. It works, it's stable.
> 
> uswsusp also has it *now*, in case you missed it. I just do not do
> benchmark runs all the time, and don't know how fast suspend2
> is. uswsusp already uses normal I/O ... and that is asynchronous.

Perhaps I was a little hasty then snipping the rest of your reply to Nigel.

You make a single point here regarding Speed, and you *may* be right. However you conveniently 
ignore all the other neat features of suspend2 that actually make it usable by stating that they 
"would/could/should" be available/doable in uswsusp. It's starting to sound like vapourware.

When I installed ubuntu 6.06 on my shiny new laptop, I pressed the hibernate button. The screen went 
black, the hard disk light locked on and it just sat there. I thought to myself "oh dear, it's 
locked up" so I pulled the battery out and restarted the machine. (Ubuntu uses the in-kernel 
swsusp). It turns out the machine was actually hibernating. Who would have known? I told me nothing 
and behaved *exactly* like a machine hard-locked. So on this one box, the in-kernel suspend actually 
works, for certain definitions of works.

On resume there is a lovely swap storm as all my apps are swapped back in. If for some reason the 
machine decides not to suspend or has a problem while doing so, I don't know about it. It just sits 
there until the battery goes flat. No progress/error reports.

And of course on my other laptop it just does weird things. I could probably help debug it if I had 
the time or inclination, but seriously.. I simply add

deb http://dagobah.ucc.asn.au/ubuntu-suspend2 dapper/

.. to my /etc/apt/sources list and type apt-get install suspend2 and all of a sudden it works. (Most 
of my machines actually run self-patched/compiled kernels, but the installation is just as easy)

Not only works, but it gives me progress information. It actually *tells* me what it's doing.. (and 
what might have gone wrong, if something does). Fancy that! And if I've hit hibernate and think "Oh 
dear, I needed to add that appointment to my calendar", I can just tap the "esc" key and it will 
abort the hibernate and put everything back where it was.

Not to mention all my apps popping back exactly the way they were, with no loss in responsiveness 
while they swap back in as soon as the machine becomes live.

I know I might be one of these strange breed of people that actually like these features, but as 
much as I love hacking, I'm sick of having to beat my machines upside the head to figure out what is 
actually going on or even make them work. Suspend2 just gives it to me out of the box, and in 
combination with the hibernate script set it works 1st time, every time.

Yes, suspend2 is more complex than what is in the kernel.. but whadda ya know.. it works. Perhaps 
that extra complexity is there for a reason..

What I'd like to see really, rather than obstinate outright rejection, is people to actually look at 
Nigel's code and give valid technical commentary on what needs to be changed, and why it needs to be 
changed. Rather than "We can do this out of tree, so we'll not accept this code". You might be able 
to do it out of tree and make it work, but the number of people using suspend2 is a pretty good 
indicator that the current in-kernel code is sub-optimal.

People want a stable, reliable hibernate, and they want it *now*. Not in the next release, or when 
someone feels like hacking on it. A number of those same people use the external suspend2 patches, 
while the rest of the population simply pine for something that works.

I know I sound like a broken record, but this has already been done to death so many times while I 
stood on the sidelines and watched. I really felt the need to throw my worthless .2c into the ring.

Let's get something that actually works into the tree.. hell we had swsusp and pmdisk in there 
"competing" for a while, and I've seen discussion about a couple of ieee802.11 stacks. Why not give 
it a try.

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: Re: Suspend2 - Request for review & inclusion in -mm

[Markus Gaugusch]

Dear Pavel (and others),

I've been a suspend user since the early days (when Gabor Kuti was working 
on it!), and I think it is really a shame that there are so many 
issues even after 5+ years.
I've recently upgraded my desktop to SuSE 10.1 with a SuSE 2.6.16 kernel 
and swsusp. It's basically working, but for example my serial interface 
with a ds2408 one wire controller attached doesn't work post resume. This 
has NEVER been a problem with suspend2 (also up to 2.6.16).

You might know that I'm the developer of Fast Online Update for SuSE 
(fou4s). The main thing about an online update is comparing versions of 
installed packages with those in the update descriptions. In the early 
days I had some packages that were just too different, so my algorithm 
didn't work. Lars Ellenberg sent me a patch with a completely rewritten 
version update code. You know, this was the HEART of my Software, and now 
I had to replace it with foreign code!? I could have told my users to wait 
another year or two and use YaST OnlineUpdate for those packages instead. 
But I decided to dump my own code in favor of -- THE USERS.

As a developer, I understand your pain to dump optimized, nice-written and 
maintainable (at least for you!) code. But who is it that we are 
developing for? Think about the USERS! There are bugs in swsusp and 
there are features (like pressing Escape during suspend) that make life 
just so much better with suspend2.

Pavel, please go beyond yourself and try to work together with Nigel. I 
know that this is hard, but in the end all people will be happy, even YOU!

regards,
Markus

-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus(at)gaugusch.at  X     Against HTML Mail
                       / \

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Andreas Jellinghaus]

swsusp does not work with swap files. suspend2 does.

so this is an inprovement. improvements are usually merged,
unless there is a reason not to.

could the discussion focus on current technical reasons why it
should not be merged? I somehow get the impression there are
personal preferences or future development strategies, but neither
looks like a current technical reason to me, and thus should not
harm merging or not.

Regards, Andreas

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[Tim Dijkstra]

On Wed, 28 Jun 2006 19:28:17 +1000
James <iphitus@gmail.com> wrote:

> People dont want promises of something working soon, they want it
> working now. And it's not like suspend2 is a half baked hack, it works
> well for more people than any other solution and works reliably. It's
> going to be months, if not years before uswsusp is ready, working, and
> as feature complete as suspend2 is now, whereas suspend2 has been
> working for me for more than 2 years.

First of all, I have nothing against suspend2, and I think the relevant people
should judge it fairly. I don't understand however why people in this thread 
keep implying that uswsusp doesn't work. On all three machines I tested it on, 
it worked fine.

It is true maybe that it is less feature complete, but the only major drawback
that the current uswsusp implementation has at the moment (IMHO) is that it only 
supports writing to swap.

I think one important reason why people have good experiences with suspend2, is 
because it comes with a nice hibernate script, which has a module blacklist.
This list will hide the fact that some drivers will make your system hang, and
that is independent of the suspend2 or uswsusp.

The CVS version of the hibernate script has some support for uswsusp btw.

grts Tim

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Pavel Machek]

On Wed 2006-06-28 01:18:10, Sebastian Kügler wrote:
> On Wednesday 28 June 2006 00:51, Pavel Machek wrote:
> > On Wed 2006-06-28 00:38:59, Sebastian Kügler wrote:
> > > On Wednesday 28 June 2006 00:22, Pavel Machek wrote:
> > > > I do not think suspend2 works on more machines than in-kernel
> > > > swsusp. Problems are in drivers, and drivers are shared.
> > > >
> > > > That means that if you have machine where suspend2 works and swsusp
> > > > does not, please tell me. I do not think there are many of them.
> > >
> > > Maybe not machines, but definitely usage scenarios. I've tried both
> > > implementations lately, and swsusp would often -- especially under high
> > > memory load -- just return from trying, while suspend2 succeeds in
> > > freeing enough memory to be able to suspend _every_ time.
> >
> > Refrigerator fixes should help with this one. Does it still happen in
> > 2.6.17?
> 
> Last release I tested was 2.6.17-rc6-git7.
> 
> > > Is that something uswsusp is likely to change anytime soon?
> >
> > Actually this is common code for both swsusp and uswsusp; yes this
> > should be fixed.
> 
> In the above mentioned release it definitely is not fixed.

Okay, can I get some details? Like how much memory does system have,
what stress test causes the failure?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Pavel Machek]

On Wed 2006-06-28 10:56:20, Andreas Jellinghaus wrote:
> swsusp does not work with swap files. suspend2 does.
> 
> so this is an inprovement. improvements are usually merged,
> unless there is a reason not to.

> could the discussion focus on current technical reasons why it
> should not be merged? I somehow get the impression there are
> personal preferences or future development strategies, but neither
> looks like a current technical reason to me, and thus should not
> harm merging or not.

suspend2 uses /proc -- vetoed by Greg. For more reasons, see archives.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm

[Pavel Machek]

Hi!

> When I installed ubuntu 6.06 on my shiny new laptop, I pressed the 
> hibernate button. The screen went black, the hard disk light locked on and 
> it just sat there. I thought to myself "oh dear, it's locked up" so I 
> pulled the battery out and restarted the machine. (Ubuntu uses the 
> in-kernel swsusp). It turns out the machine was actually hibernating. Who 
> would have known? I told me nothing and behaved *exactly* like a machine 
> hard-locked. So on this one box, the in-kernel suspend actually works, for 
> certain definitions of works.

Increase console loglevel if you want to see the messages, this is
FAQ.

> And of course on my other laptop it just does weird things. I could 
> probably help debug it if I had the time or inclination, but seriously.. I 
> simply add
> 
> deb http://dagobah.ucc.asn.au/ubuntu-suspend2 dapper/

Okay, so do that and bye bye...

> Yes, suspend2 is more complex than what is in the kernel.. but whadda ya 
> know.. it works. Perhaps that extra complexity is there for a
> reason..

Perhaps not. Even Nigel understands that compression/encryption does
not _have_ to be there.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Sebastian Kügler]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

Hi Pavel,

On Wednesday 28 June 2006 21:53, Pavel Machek wrote:
> Okay, can I get some details? Like how much memory does system have,
> what stress test causes the failure?

The machine has 1GB of RAM, filling it up beyond 500MB, maybe 600MB usually 
made swsusp a problem. I'd need to close apps then to be able to suspend.

Using suspend2 fixes that for me. I can even decide how much memory I want 
suspended, the rest will be reliably discarded. I did a benchmark on two 
similar machines swsusp: would take 45 seconds until resume (that's about the 
same time it takes it to boot normally) suspend2 would take 25 seconds (and 
have warm caches as a bonus). Not having a progress indicator also doesn't 
really help.

Another thing I really like about suspend2 is that I can easily set it up so 
it goes into S3 after writing the image. It would resume much faster then, 
and in case it runs out of battery, I can still 'normally' resume from disk. 
That's incredibly useful, especially since not all devices are known to 
completely switch off during S3, and resuming from S3 is generally known to 
cause problems. I've yet to see suspend2 failing though.

Is such a disk-backed hibernate also possible with (u)swsusp?

Cheers,
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
So many beautiful women and so little time. - John Barrymore


[-- Attachment #2: Type: application/pgp-signature, Size: 483 bytes --]

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Pavel Machek]

Hi!

> > Okay, can I get some details? Like how much memory does system have,
> > what stress test causes the failure?
> 
> The machine has 1GB of RAM, filling it up beyond 500MB, maybe 600MB usually 
> made swsusp a problem. I'd need to close apps then to be able to
> suspend.

I'm pretty sure I do suspending with most of RAM full. You have
big-enough swap partition, right?

> Using suspend2 fixes that for me. I can even decide how much memory I want 
> suspended, the rest will be reliably discarded. I did a benchmark on two 
> similar machines swsusp: would take 45 seconds until resume (that's about the 
> same time it takes it to boot normally) suspend2 would take 25 seconds (and 
> have warm caches as a bonus). Not having a progress indicator also doesn't 
> really help.

Set console loglevel (see Doc*/power/swsusp.txt), and you should get
some progress. But yes, swsusp is slow; uswsusp should be about the
same speed as suspend2.

> Another thing I really like about suspend2 is that I can easily set it up so 
> it goes into S3 after writing the image. It would resume much faster then, 
> and in case it runs out of battery, I can still 'normally' resume from disk. 
> That's incredibly useful, especially since not all devices are known to 
> completely switch off during S3, and resuming from S3 is generally known to 
> cause problems. I've yet to see suspend2 failing though.

> Is such a disk-backed hibernate also possible with (u)swsusp?

We call it s2both and yes, it is supported.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Sebastian Kügler]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Thursday 29 June 2006 00:24, Pavel Machek wrote:
> > > Okay, can I get some details? Like how much memory does system have,
> > > what stress test causes the failure?
> >
> > The machine has 1GB of RAM, filling it up beyond 500MB, maybe 600MB
> > usually made swsusp a problem. I'd need to close apps then to be able to
> > suspend.
>
> I'm pretty sure I do suspending with most of RAM full. You have
> big-enough swap partition, right?

1 GB, it might not be completely empty though. I probably only hit swsusp 
limit much earlier than suspend2's (which after 34 suspend/resume cycles and 
heavy use in between I did not hit yet). 
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mohandas K. Gandhi often changed his mind publicly. An aide once asked him how 
he could so freely contradict this week what he had said just last week. The 
great man replied that it was because this week he knew better.


[-- Attachment #2: Type: application/pgp-signature, Size: 483 bytes --]

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Pavel Machek]

On Thu 2006-06-29 00:37:57, Sebastian Kügler wrote:
> On Thursday 29 June 2006 00:24, Pavel Machek wrote:
> > > > Okay, can I get some details? Like how much memory does system have,
> > > > what stress test causes the failure?
> > >
> > > The machine has 1GB of RAM, filling it up beyond 500MB, maybe 600MB
> > > usually made swsusp a problem. I'd need to close apps then to be able to
> > > suspend.
> >
> > I'm pretty sure I do suspending with most of RAM full. You have
> > big-enough swap partition, right?
> 
> 1 GB, it might not be completely empty though. I probably only hit swsusp 
> limit much earlier than suspend2's (which after 34 suspend/resume cycles and 
> heavy use in between I did not hit yet). 

Okay, can we get bugzilla.kernel.org report? (assigned-to me)

This really should not happen, and I did not see swsusp fail like that
for quite a long time. I _could_ make it fail with make -j on kernel,
and similar crazy loads, but on nothing reasonable.

dmesg from failed run would be nice, too.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Rafael J. Wysocki]

Hi,

On Thursday 29 June 2006 00:19, Sebastian Kügler wrote:
> On Wednesday 28 June 2006 21:53, Pavel Machek wrote:
> > Okay, can I get some details? Like how much memory does system have,
> > what stress test causes the failure?
> 
> The machine has 1GB of RAM, filling it up beyond 500MB, maybe 600MB usually 
> made swsusp a problem. I'd need to close apps then to be able to suspend.

That sounds strange to me as I have never had any problems of this kind with
swsusp and I sometimes have RAM almost 100% full before suspend
(there's 1.5 GB on my box).

First, have you tried setting the size of the image using /sys/power/image_size?

Second, the swsusp's memory shrinker has been reworked recently and the
patch should be in the latest git.  Could you please check if the problems persist
with the newest -git kernels?

Greetings,
Rafael

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Sebastian Kügler]

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

On Thursday 29 June 2006 00:46, Pavel Machek wrote:
> On Thu 2006-06-29 00:37:57, Sebastian Kügler wrote:
> > On Thursday 29 June 2006 00:24, Pavel Machek wrote:
> > > > > Okay, can I get some details? Like how much memory does system
> > > > > have, what stress test causes the failure?
> > > >
> > > > The machine has 1GB of RAM, filling it up beyond 500MB, maybe 600MB
> > > > usually made swsusp a problem. I'd need to close apps then to be able
> > > > to suspend.
> > >
> > > I'm pretty sure I do suspending with most of RAM full. You have
> > > big-enough swap partition, right?
> >
> > 1 GB, it might not be completely empty though. I probably only hit swsusp
> > limit much earlier than suspend2's (which after 34 suspend/resume cycles
> > and heavy use in between I did not hit yet).

I'll try to see what I can do, it might take some time though. Quite busy at 
the moment and preparing for vacation, lucky me. :-)

And to be honest, since suspend2 works perfectly well here, it's not extremely 
high on my list of priorities (talking about scratching an itch), swsusp just 
misses too much stuff I heavily rely upon, and I'm used to for years. Sad 
enough I have to go through this again, after having helped out with testing 
suspend2 for more than three years.

> Okay, can we get bugzilla.kernel.org report? (assigned-to me)
>
> This really should not happen, and I did not see swsusp fail like that
> for quite a long time. I _could_ make it fail with make -j on kernel,
> and similar crazy loads, but on nothing reasonable.
>
> dmesg from failed run would be nice, too.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Nothing ever becomes real until it is experienced. - John Keats


[-- Attachment #2: Type: application/pgp-signature, Size: 483 bytes --]

Re: swsusp / suspend2 reliability (was Re: [Suspend2-devel] Re: Suspend2 - Request for review & inclusion in -mm)

[Sebastian Kügler]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

On Thursday 29 June 2006 00:52, Rafael J. Wysocki wrote:
> On Thursday 29 June 2006 00:19, Sebastian Kügler wrote:
> > On Wednesday 28 June 2006 21:53, Pavel Machek wrote:
> > > Okay, can I get some details? Like how much memory does system have,
> > > what stress test causes the failure?
> >
> > The machine has 1GB of RAM, filling it up beyond 500MB, maybe 600MB
> > usually made swsusp a problem. I'd need to close apps then to be able to
> > suspend.
>
> That sounds strange to me as I have never had any problems of this kind
> with swsusp and I sometimes have RAM almost 100% full before suspend
> (there's 1.5 GB on my box).
>
> First, have you tried setting the size of the image using
> /sys/power/image_size?

Nope, didn't try that (and only just now read in the docs that it existed).

> Second, the swsusp's memory shrinker has been reworked recently and the
> patch should be in the latest git.  Could you please check if the problems
> persist with the newest -git kernels?

I'll see what I can do, but as I said in the other email, time is limited at 
the moment.

Thanks for the pointer, though.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Perfection is achieved not when you have nothing more to add, but when you 
have nothing left to take away. - Antoine de Saint-Exupery


[-- Attachment #2: Type: application/pgp-signature, Size: 483 bytes --]

Re: swsusp / suspend2 reliability

[Jan Rychter]

>>>>> "Pavel" == Pavel Machek <pavel@suse.cz> writes:
 Pavel> Hi!
 >> > uswsusp is a great idea, really.. I love it.. but suspend2 is
 >> > here, it works, it's stable and it's now. Why continue to deprive
 >> > the mainstream of these features because "uswsusp should".. as yet
 >> > it doesn't.. and when it does then we can phase out the currently
 >> > stable, working alternative that has all these features that
 >> > uswsusp _will_ have, after it's had them for a year or so and its
 >> > been proven stable. Not only that, I'll be happy to migrate over
 >> > to it. Until then however, you can pry suspend2.. cold,
 >> > dead.. blah blah..
 >>
 >> Given the above explanation, it's obvious that I'm an outside
 >> watcher now, but if swsusp2 success rate is clearly higher than the
 >> standard version, then I'd also strongly advocate this direction
 >> since, quite frankly,

 Pavel> I do not think suspend2 works on more machines than in-kernel
 Pavel> swsusp. Problems are in drivers, and drivers are shared.

 Pavel> That means that if you have machine where suspend2 works and
 Pavel> swsusp does not, please tell me. I do not think there are many
 Pavel> of them.

Accept the facts -- for some reason, there is a fairly large user base
that goes to all the bother of using suspend2, which requires
downloading, patching and all the extra work. People do it, in spite of
the wonderful swsusp being in the kernel and all the other extra cool
stuff being worked on.

That is a fact, and all the hand waving won't change it.

I'm tired of this. It's taking years for Linux to get reasonably working
suspend facilities, which is a shame. In my opinion a large part of the
problem is you opposing Nigel's patches. Problem is, for many people
Nigel's code works while yours does not.

One thing to note here: "works" means "suspends and resumes every
time". It doesn't mean "doesn't suspend when blah blah" or "suspends
unless driver X does Y, then it panics" or "suspends most of the time,
except when it says BUG() because that's clearly the right thing to
do". Try using a Mac to see how suspend should work.

I strongly believe suspend2 should be included in the mainstream
kernels, at least to give people the choice and get it on equal footing
with the other implementations.

--J.

Re: swsusp / suspend2 reliability

[Pavel Machek]

Hi!

>  Pavel> I do not think suspend2 works on more machines than in-kernel
>  Pavel> swsusp. Problems are in drivers, and drivers are shared.
> 
>  Pavel> That means that if you have machine where suspend2 works and
>  Pavel> swsusp does not, please tell me. I do not think there are many
>  Pavel> of them.
> 
> Accept the facts -- for some reason, there is a fairly large user base
> that goes to all the bother of using suspend2, which requires
...
> That is a fact, and all the hand waving won't change it.

Users like suspend2 eye candy => swsusp must be unreliable?

I know users that installed swsusp, decided they want progress bars,
and went for suspend2.

> I'm tired of this. It's taking years for Linux to get reasonably working
> suspend facilities, which is a shame. In my opinion a large part of the
> problem is you opposing Nigel's patches. Problem is, for many people
> Nigel's code works while yours does not.

Nigel only submitted his code once, month or so ago, as series of 200
or so patches. Do not blame me for _that_.

							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [Suspend2-devel] Re: swsusp / suspend2 reliability

[Rohan Dhruva]

This is turning into an ugly flamewar that will help no one. Why not
take the best from both swsusp and suspend2, and get a nice
implementation into the kernel, that works most of the times ! About
time, already.

I know its easy to sit back and say 'do it', however, atleast it is
time already to stop this war. This 'suxrulz' thing is helping no one.

Rohan.

-- 
Rohan Dhruva
Proud GNU/Linux user.
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming or what?"
http://www.dhruva.be/

Re: [Suspend2-devel] Re: swsusp / suspend2 reliability

[dirk husemann]

[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]

Pavel Machek wrote:
> Hi!
>
>   
>>  Pavel> I do not think suspend2 works on more machines than in-kernel
>>  Pavel> swsusp. Problems are in drivers, and drivers are shared.
>>
>>  Pavel> That means that if you have machine where suspend2 works and
>>  Pavel> swsusp does not, please tell me. I do not think there are many
>>  Pavel> of them.
>>
>> Accept the facts -- for some reason, there is a fairly large user base
>> that goes to all the bother of using suspend2, which requires
>>     
> ...
>   
>> That is a fact, and all the hand waving won't change it.
>>     
>
> Users like suspend2 eye candy => swsusp must be unreliable?
>   
oh, come on. that's a pretty cheap argument. let me tell you i tried
swsusp (admittedly a while ago) couldn't get it to run reliably on
several laptops, went for suspend2 --- and it worked rather well. i
certainly didn't go for suspend2 because of its "eye candy"...

this is not about eye candy, this is about pragmatism: suspend2 seems to
work on a lot more platforms than what is currently in the kernel.
> I know users that installed swsusp, decided they want progress bars,
> and went for suspend2.
>
>   
>> I'm tired of this. It's taking years for Linux to get reasonably working
>> suspend facilities, which is a shame. In my opinion a large part of the
>> problem is you opposing Nigel's patches. Problem is, for many people
>> Nigel's code works while yours does not.
>>     
>
> Nigel only submitted his code once, month or so ago, as series of 200
> or so patches. Do not blame me for _that_.
>   
IIRC correctly he did try earlier and was told to come back when he had
his code subdivided in little pieces.

    dirk

-- 
Dr Dirk Husemann, Pervasive Computing, IBM Research, Zurich Research Lab
	hud@zurich.ibm.com --- http://www.zurich.ibm.com/~hud/
       PGP key: http://www.zurich.ibm.com/~hud/contact/PGP
  PGP Fingerprint: 983C 48E7 0A78 A313 401C  C4AD 3C0A 278E 6431 A149
	     Email only authentic if signed with PGP key.

Appended to this email is an electronic signature attachment. You can
ignore it if your email program does not know how to verify such a
signature. If you'd like to learn more about this topic, www.gnupg.org
is a good starting point.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: swsusp / suspend2 reliability

[Avuton Olrich]

On 7/6/06, Jan Rychter <jan@rychter.com> wrote:
> >>>>> "Pavel" == Pavel Machek <pavel@suse.cz> writes:
>  Pavel> Hi!
>  >> > uswsusp is a great idea, really.. I love it.. but suspend2 is
>  >> > here, it works, it's stable and it's now. Why continue to deprive
>  >> > the mainstream of these features because "uswsusp should".. as yet
>  >> > it doesn't.. and when it does then we can phase out the currently
>  >> > stable, working alternative that has all these features that
>  >> > uswsusp _will_ have, after it's had them for a year or so and its
>  >> > been proven stable. Not only that, I'll be happy to migrate over
>  >> > to it. Until then however, you can pry suspend2.. cold,
>  >> > dead.. blah blah..
>  >>
>  >> Given the above explanation, it's obvious that I'm an outside
>  >> watcher now, but if swsusp2 success rate is clearly higher than the
>  >> standard version, then I'd also strongly advocate this direction
>  >> since, quite frankly,
>
>  Pavel> I do not think suspend2 works on more machines than in-kernel
>  Pavel> swsusp. Problems are in drivers, and drivers are shared.
>
>  Pavel> That means that if you have machine where suspend2 works and
>  Pavel> swsusp does not, please tell me. I do not think there are many
>  Pavel> of them.
>
> Accept the facts -- for some reason, there is a fairly large user base
> that goes to all the bother of using suspend2, which requires
> downloading, patching and all the extra work. People do it, in spite of
> the wonderful swsusp being in the kernel and all the other extra cool
> stuff being worked on.

As I've said in previous threads, I've had a much higher rate of
sucess with suspend2 than swsusp, much like others who are replying to
this thread. Can anyone tell me, did Suspend2 get veto'd? If not has
there been a clear laid-out plan of what needs to be done to get this
in to the kernel? Is adding new in-kernel suspend code not an option
now? This is not about eye-candy but simply getting computers to
suspend-to-disk. If that part of suspend2 never makes it into the
kernel I couldn't care less.
-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: swsusp / suspend2 reliability

[grundig]

El Fri, 7 Jul 2006 08:19:21 -0700,
"Avuton Olrich" <avuton@gmail.com> escribió:

> As I've said in previous threads, I've had a much higher rate of
> sucess with suspend2 than swsusp, much like others who are replying to
> this thread. Can anyone tell me, did Suspend2 get veto'd? If not has
> there been a clear laid-out plan of what needs to be done to get this
> in to the kernel? Is adding new in-kernel suspend code not an option
> now? This is not about eye-candy but simply getting computers to

There's probably a high resistance at doing such thing, and I don't
think suspend2 developers should take it as "discrimination". As I
understand the development in the linux land, I could find the
following reasons for not doing such thing:

2.6 is supposed to be a stable release. There has been many 
"merge $FOO2, because is better than $FOO" experiments in the
past, and they have not been fun, in many cases they have been
_rejected_ even if they worked better. Reason? Regressions.
Mergin One Big Thing (be it splitted in 200 different patches
or not suspend2 it's a One Big Thing) always is painful - the
linux style these days is to "improve" things

As much as people may dislike swsusp, it's merged in the main
tree, and this means it has _lots_ of users, and hence more
probabilities of being tested in machines where it doesn't
works for god-know-what-reason, and more probabilities of
getting hate-mail. Suspend2 may work in many cases where
swsusp does not (for whatever reason), but the contrary 
can be also be true, and "It Works For Me" it's not a good
measure at all for taking such decisions. I bet most of
the non-suspend2/swsusp developers wold rather fix swsusp
rather than replacing it with a "undertested" (it's not in
the main tree) solution.

You may ask "why not merge suspend2", but from an objective
POV it's perfectly fine that some people asks "why don't
suspend2 people try to improve swsusp instead of rewritting
it? It may be easier to fix swsusp than replacint it with
suspend2"

(Personally I don't use suspend2 or swsusp, real men never
switch off their computers)

Re: swsusp / suspend2 reliability

[Olivier Galibert]

On Fri, Jul 07, 2006 at 06:09:39PM +0200, grundig wrote:
> You may ask "why not merge suspend2", but from an objective
> POV it's perfectly fine that some people asks "why don't
> suspend2 people try to improve swsusp instead of rewritting
> it? It may be easier to fix swsusp than replacint it with
> suspend2"

Suspend2 is an improvement on swsusp.  What Pavel wants is something
completely different and even less tested that suspend2 called
uswsusp.

  OG.

Re: swsusp / suspend2 reliability

[Olivier Galibert]

On Fri, Jul 07, 2006 at 01:50:31PM +0000, Pavel Machek wrote:
> I know users that installed swsusp, decided they want progress bars,
> and went for suspend2.

I know users that installed swsusp, decided they wanted working
suspend, and brought a mac.


> Nigel only submitted his code once, month or so ago, as series of 200
> or so patches. Do not blame me for _that_.

Nigel submitted his code on 2004-09-16, 2004-11-24, 2005-07-05,
2006-01-25, 2006-03-28 and 2006-06-26.

  OG.

Re: [Suspend2-devel] Re: swsusp / suspend2 reliability

[David Fox]

Rohan Dhruva wrote:
> Why not
> take the best from both swsusp and suspend2, and get a nice
> implementation into the kernel, that works most of the times !

Well, this is the ten thousand dollar question - why not indeed?  Pavel 
says "Problems are in drivers, and drivers are shared", but suspend2 
works around this by unloading certain drivers before suspending, and 
otherwise hacking around the difficulties.  This is, I think, what is 
meant when suspend2 is said to support scripting.  It may not be a 
pleasing approach from a theoretical standpoint, but it seems to be the 
only way to get a reliable implementation in a timely fashion -- 
reliable in the sense of being most likely to work on a randomly chosen 
machine without custom configuration.

RE: swsusp / suspend2 reliability

[Hua Zhong]

> Accept the facts -- for some reason, there is a fairly large 
> user base that goes to all the bother of using suspend2, 
> which requires downloading, patching and all the extra work. 
> People do it, in spite of the wonderful swsusp being in the 
> kernel and all the other extra cool stuff being worked on.
> 
> That is a fact, and all the hand waving won't change it.

Truth is always painful. :-)

Greg had a good article on LWN: http://lwn.net/Articles/189467/. There you could find a more painful truth. You know what the real
reason is that suspend2 couldn't get merged? Not Nigel, not Pavel, but Linus, because he personally doesn't care. So if you want to
have a high-quality suspend-to-disk, your best bet is to convince Linus to use it. :-)

(well I'm partly joking here, but the above article and the corresponding thread is a well-worthy read
(http://thread.gmane.org/gmane.linux.power-management.general/1884/focus=1884).

Some of the Linus quotes that you may find interesting :-)
http://article.gmane.org/gmane.linux.power-management.general/1974
http://article.gmane.org/gmane.linux.power-management.general/1996
http://article.gmane.org/gmane.linux.power-management.general/2105
http://article.gmane.org/gmane.linux.power-management.general/2193

Re: swsusp / suspend2 reliability

[Alon Bar-Lev]

On 7/7/06, Hua Zhong <hzhong@gmail.com> wrote:
> Greg had a good article on LWN: http://lwn.net/Articles/189467/. There you could find a more painful truth. You know what the real
> reason is that suspend2 couldn't get merged? Not Nigel, not Pavel, but Linus, because he personally doesn't care. So if you want to
> have a high-quality suspend-to-disk, your best bet is to convince Linus to use it. :-)
>

True.
That's right.
In the past someone called it a lack of leadership...

But reading the references you introduced, I've first realized in how
deep problem we, the user community who want to use suspend-to-disk
and not suspend-to-ram, are.

It is so pity that the whole suspend (ram AND disk) process is not
addressed as a whole... Just because Linus does not care.

And if suspend-to-disk is more complex, it should be solved first,
since suspend-to-ram can be a subset of the process (Although people
in the past dismissed this claim... :( ).

So I guess we will continue to use suspend2 for a long while... Since
at least someone cares, and have a vision reacher than hay I can do
this in userspace.

Best Regards,
Alon Bar-Lev.

Re: swsusp / suspend2 reliability

[Pavel Machek]

On Fri 07-07-06 19:44:24, Olivier Galibert wrote:
> On Fri, Jul 07, 2006 at 06:09:39PM +0200, grundig wrote:
> > You may ask "why not merge suspend2", but from an objective
> > POV it's perfectly fine that some people asks "why don't
> > suspend2 people try to improve swsusp instead of rewritting
> > it? It may be easier to fix swsusp than replacint it with
> > suspend2"
> 
> Suspend2 is an improvement on swsusp.  What Pavel wants is something
> completely different and even less tested that suspend2 called
> uswsusp.

...which is already merged in 2.6.17, BTW. So what Pavel wants can be
translated as 'please use already merged code, it can already do what
you want without further changing kernel'.

							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [Suspend2-devel] Re: swsusp / suspend2 reliability

[Pavel Machek]

Hi!

> >Why not
> >take the best from both swsusp and suspend2, and get a 
> >nice
> >implementation into the kernel, that works most of the 
> >times !
> 
> Well, this is the ten thousand dollar question - why not 
> indeed?  Pavel says "Problems are in drivers, and 
> drivers are shared", but suspend2 works around this by 
> unloading certain drivers before suspending, and 
> otherwise hacking around the difficulties.  This is, I 
> think, what is meant when suspend2 is said to support 
> scripting.

Well, you do make same hacks with swsusp; powersaved does that for
example.

>  It may not be a pleasing approach from a 
> theoretical standpoint, but it seems to be the only way 

...but as it is not pleasing, it can't go anywhere near mainline.

							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: swsusp / suspend2 reliability

[Olivier Galibert]

On Fri, Jul 07, 2006 at 09:39:17PM +0000, Pavel Machek wrote:
> ...which is already merged in 2.6.17, BTW.

Sure.  It's a stupid approach, but since you have your name in the
MAINTAINERS file, you don't have to care.  Meanwhile, those who would
like a reliable suspend are out of luck.


> So what Pavel wants can be
> translated as 'please use already merged code, it can already do what
> you want without further changing kernel'.

Like we'd want to use unreviewed, extremely new and risky code for
something that happily destroy filesystems.

  OG.

Re: swsusp / suspend2 reliability

[Pavel Machek]

On Fri 2006-07-07 20:03:08, Olivier Galibert wrote:
> On Fri, Jul 07, 2006 at 01:50:31PM +0000, Pavel Machek wrote:
> > I know users that installed swsusp, decided they want progress bars,
> > and went for suspend2.
> 
> I know users that installed swsusp, decided they wanted working
> suspend, and brought a mac.
> 
> 
> > Nigel only submitted his code once, month or so ago, as series of 200
> > or so patches. Do not blame me for _that_.
> 
> Nigel submitted his code on 2004-09-16, 2004-11-24, 2005-07-05,
> 2006-01-25, 2006-03-28 and 2006-06-26.

Lets check for example 2006-03-28...

No... this is not submission of suspend2. It is info that new version
of it is available, with only url (!) of .tar.bz2 (!) given. With no
signed-off-by: headers, no patches, no changelogs.

Read relevant documentation if you want to know how patch submission
looks.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: swsusp / suspend2 reliability

[Pavel Machek]

Hi!

> >>  Pavel> I do not think suspend2 works on more machines than in-kernel
> >>  Pavel> swsusp. Problems are in drivers, and drivers are shared.
> >>
> >>  Pavel> That means that if you have machine where suspend2 works and
> >>  Pavel> swsusp does not, please tell me. I do not think there are many
> >>  Pavel> of them.
> >>
> >> Accept the facts -- for some reason, there is a fairly large user base
> >> that goes to all the bother of using suspend2, which requires
> >>     
> > ...
> >   
> >> That is a fact, and all the hand waving won't change it.
> >>     
> >
> > Users like suspend2 eye candy => swsusp must be unreliable?
> >   
> oh, come on. that's a pretty cheap argument. let me tell you i tried
> swsusp (admittedly a while ago) couldn't get it to run reliably on

Can you retry with recent version and generate proper bugreport if it
is still broken?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp / suspend2 reliability

[Pavel Machek]

> > So what Pavel wants can be
> > translated as 'please use already merged code, it can already do what
> > you want without further changing kernel'.
> 
> Like we'd want to use unreviewed, extremely new and risky code for
> something that happily destroy filesystems.

You can either use suspend2 (14000 lines of unreviewed kernel code,
old) or uswsusp (~500 lines of reviewed kernel code, ~2000 lines of
unreviewed userspace code, new).

Of course, you can also use swsusp (~2000 lines of reviewed kernel
code, pretty old) if stability matters to you more than graphical
progress bar.

I know what I'm picking, and I'm pretty sure I know what
mainline/distros will pick.

If you want to help, you are welcome to test/review any component. But
stop producing hot air.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: swsusp / suspend2 reliability

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

Hi.

On Saturday 08 July 2006 09:25, Pavel Machek wrote:
> > > So what Pavel wants can be
> > > translated as 'please use already merged code, it can already do what
> > > you want without further changing kernel'.
> >
> > Like we'd want to use unreviewed, extremely new and risky code for
> > something that happily destroy filesystems.
>
> You can either use suspend2 (14000 lines of unreviewed kernel code,
> old) or uswsusp (~500 lines of reviewed kernel code, ~2000 lines of
> unreviewed userspace code, new).

I was going to keep quiet, but I have to say this: If Suspend2 can rightly be 
called unreviewed code, it's only because you've been too busy flaming etc to 
give it serious review. Personally, though, I don't think it's right to call 
it unreviewed. I've had and applied feedback from lots of people over time 
(hch, Rafael, Pekka(sp?), Nick, Con and Hugh to name just a few). If they 
weren't reviewing the code, what were they doing?

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: swsusp / suspend2 reliability

[Christian Trefzer]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

On Sat, Jul 08, 2006 at 12:10:38AM +0300, Alon Bar-Lev wrote:
> And if suspend-to-disk is more complex, it should be solved first,
> since suspend-to-ram can be a subset of the process (Although people
> in the past dismissed this claim... :( ).

IMHO this is a bit ironic. Generally, if there is a complex problem that
can be divided in smaller parts, which are possible to address one at a
time, this should be the preferred way! Divide and conquer, my friend : )

Applied to the suspend dilemma: once we get suspend2ram working
perfectly, the only thing we still have to care for is saving the memory
image someplace, right before telling the hardware to sleep or switch
off. You might get the benefit of chosing between power-off for ultimate
power savings vs. speedy suspend2ram, yet with a backup on disk in case
something weird happens to the power supply. Nice, huh?


> So I guess we will continue to use suspend2 for a long while... Since
> at least someone cares, and have a vision reacher than hay I can do
> this in userspace.

I've been a happy suspend2 user for quite some time now, and I have to
admit I don't much care how broken the design is - for now it works, the
only alternative is just as broken, and did not work as well last time I
checked. And heck, I just don't have time to check with every new kernel
I build. Talk about working setup vs. academic progress, which in turn
will lead to a clean working setup maybe some time soon, may be later,
but not now. I'll look into it as soon as any progress is visible and
time available), s2ram is nice even on a laptop without battery ; )


Kind regards, and welcome to suspend2 family!

Chris

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [Suspend2-devel] Re: swsusp / suspend2 reliability

[Pavel Machek]

On Sat 2006-07-08 09:33:00, Nigel Cunningham wrote:
> Hi.
> 
> On Saturday 08 July 2006 09:25, Pavel Machek wrote:
> > > > So what Pavel wants can be
> > > > translated as 'please use already merged code, it can already do what
> > > > you want without further changing kernel'.
> > >
> > > Like we'd want to use unreviewed, extremely new and risky code for
> > > something that happily destroy filesystems.
> >
> > You can either use suspend2 (14000 lines of unreviewed kernel code,
> > old) or uswsusp (~500 lines of reviewed kernel code, ~2000 lines of
> > unreviewed userspace code, new).
> 
> I was going to keep quiet, but I have to say this: If Suspend2 can rightly be 
> called unreviewed code, it's only because you've been too busy flaming etc to 
> give it serious review. Personally, though, I don't think it's right to call 
> it unreviewed. I've had and applied feedback from lots of people over time 
> (hch, Rafael, Pekka(sp?), Nick, Con and Hugh to name just a few). If they 
> weren't reviewing the code, what were they doing?

Well, you are right that Rafael did some quite serious reviewing of
latest incarnation... OTOH you got some pretty big comments ("may not
use /proc") that were not included, yet (and will need big changes),
so it is not really reviewed, either. (Certainly swsusp in-kernel code
got more reviewing over the years).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: swsusp / suspend2 reliability

[Bojan Smojver]

On Sat, 2006-07-08 at 01:25 +0200, Pavel Machek wrote:

> You can either use suspend2 (14000 lines of unreviewed kernel code,
> old) or uswsusp (~500 lines of reviewed kernel code, ~2000 lines of
> unreviewed userspace code, new).
> 
> Of course, you can also use swsusp (~2000 lines of reviewed kernel
> code, pretty old) if stability matters to you more than graphical
> progress bar.

I've been using Suspend2 on my notebook for a long, long time now and
the code is not unstable. In fact, I never reboot my system unless there
is a kernel upgrade from Fedora. And I do suspend/resume many times
every day, sometimes on AC power, sometimes on battery. And I never lost
one bit of information on my file system as a result of Suspend2 stuff
up.

Also, Suspend2 can do many things that neither swsusp or even uswsusp
can do, like suspending to regular files, swap files or combination of
swap, swapfiles and regular files. It is also *much* faster than swsusp,
to the point that it takes less time to resume *full* image of memory
with Suspend2 than it takes half memory with swsusp. It easy to confuse
people by comparing apples and oranges, so let's not do that.

So, the code may be "unreviewed", but it is sure field tested. And by
many, not just me.

-- 
Bojan

uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Pavel Machek]

Hi!

> > > > So what Pavel wants can be
> > > > translated as 'please use already merged code, it can already do what
> > > > you want without further changing kernel'.
> > >
> > > Like we'd want to use unreviewed, extremely new and risky code for
> > > something that happily destroy filesystems.
> >
> > You can either use suspend2 (14000 lines of unreviewed kernel code,
> > old) or uswsusp (~500 lines of reviewed kernel code, ~2000 lines of
> > unreviewed userspace code, new).
> 
> I was going to keep quiet, but I have to say this: If Suspend2 can rightly be 
> called unreviewed code, it's only because you've been too busy flaming etc to 
> give it serious review. Personally, though, I don't think it's right

I really looked at suspend2 hard, year or so ago, when I was pretty
tired of the flamewars. At that point I decided it is way too big to
be acceptable to mainline, and got that crazy idea about uswsusp, that
surprisingly worked out at the end.

uswsusp makes suspend2 obsolete, and suspend2 now looks
misdesigned. It puts too much stuff into the kernel, you know that
already.

>From your point of view, uswsusp is misdesigned, too. It is too damn
hard to install. There's no way it could survive as a standalone patch
-- the way suspend2 survives. Fortunately, from distro point of view,
being hard to install does not matter that much. Distros already have
their own initrds, etc. And in the long term, distros matter, and I'm
quite confident I can make 90% distributions ship uswsusp + its
userland; cleaner kernel code matters, too, and maybe you'll agree
that if you only look at the kernel parts, uswsusp looks nicer.

Now, you are asking me to review 14000 lines of code. That's quite a
lot of code, and you did not exactly make reviewer's life easy. Also
reviews usually stop at first "fatal" problem, and you still drive
user interface from kernel. (Yes, drawing is done in userland, but
core user interface code is still in kernel). That is "fatal".

(Greg mentioned /proc usage being "fatal", too).

Now... moving user interface into userland, and removing /proc usage
are big tasks, do you agree? And they will mean lot of changes, and
lot of new testing.

Perhaps at this point right solution is to just drop suspend2
codebase, and do it again, this time in userland? Kernel
infrastructure is already there, and even if you wanted to replace
[u]swsusp by suspend2, you have to understand how the old code
works. (Another point you may like is that forking suspend.sf.net code
is relatively easy; so even if we disagree about coding style of the
userland parts, I can't veto it or something. And given that your only
problem is including all the possible features, I probably will not
have reason to stop you or something -- having all the features is
okay in userland).

Now... switching to uswsusp kernel parts will make it slightly harder
to install in the short term (messing with initrd). OTOH there's at
least _chance_ to get to the point where suspend "just works" in
Linux, in the long term...

(Of course, you can just ignore this and keep maintaining out-of-tree
suspend2. We'll also get to the point where it "just works"... it will
just take a little longer.)

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 5255 bytes --]

Hi.

On Saturday 08 July 2006 10:28, Pavel Machek wrote:
> I really looked at suspend2 hard, year or so ago, when I was pretty
> tired of the flamewars. At that point I decided it is way too big to
> be acceptable to mainline, and got that crazy idea about uswsusp, that
> surprisingly worked out at the end.
>
> uswsusp makes suspend2 obsolete, and suspend2 now looks
> misdesigned. It puts too much stuff into the kernel, you know that
> already.

No, I don't. From my point of view, uswsusp is misdesigned, but suspend2 
isn't. Suspend2 keeps the stuff that ought to be done by the kernel in the 
kernel. It doesn't shift data out to userspace, only to copy it straight back 
to the kernel for I/O. It will keep working even if userspace crashes and 
burns. It leverages support for compression and encryption that's already in 
the kernel. It does a real image of memory, not a half-pie attempt that 
causes lots of faulting of pages etc post-resume. If there's any misdesign in 
Suspend2, it's that I haven't made it a special case of checkpointing. But, 
of course, there's no support for checkpointing in the rest of the kernel at 
the moment anyway.

> From your point of view, uswsusp is misdesigned, too. It is too damn
> hard to install. There's no way it could survive as a standalone patch
> -- the way suspend2 survives. Fortunately, from distro point of view,
> being hard to install does not matter that much. Distros already have
> their own initrds, etc. And in the long term, distros matter, and I'm
> quite confident I can make 90% distributions ship uswsusp + its
> userland; cleaner kernel code matters, too, and maybe you'll agree
> that if you only look at the kernel parts, uswsusp looks nicer.

It looks simple, I agree. But that's only because it's doing the minimum 
required.

> Now, you are asking me to review 14000 lines of code. That's quite a
> lot of code, and you did not exactly make reviewer's life easy. Also
> reviews usually stop at first "fatal" problem, and you still drive
> user interface from kernel. (Yes, drawing is done in userland, but
> core user interface code is still in kernel). That is "fatal".

I agree that I didn't do the best job of making the reviewer's life easy. But 
let's give me some credit. I did all those patches because I genuinely 
thought that's what was requested the last time I submitted patches for 
review. I didn't like splitting up the files into all those patches - it was 
a lot of work and took a lot of time. But I did it because I wanted to do 
what was asked and wanted to do what was necessary to get a good 
implementation into the vanilla kernel.

Frankly, I'd rather be working on improving drivers and helping implement the 
run-time power management than working on getting Suspend2 merged. But for 
now, this is the immediate task.

I don't know why you see the user interface code as a problem. All the kernel 
is doing is telling the userspace program, via a netlink socket, what's going 
on and receiving messages from the userspace program sometimes.

> (Greg mentioned /proc usage being "fatal", too).

> Now... moving user interface into userland, and removing /proc usage
> are big tasks, do you agree? And they will mean lot of changes, and
> lot of new testing.

Removing /proc isn't a big task. It will affect the hibernate script far more 
that the kernel code. The user interface is already in userland.

> Perhaps at this point right solution is to just drop suspend2
> codebase, and do it again, this time in userland? Kernel
> infrastructure is already there, and even if you wanted to replace
> [u]swsusp by suspend2, you have to understand how the old code
> works. (Another point you may like is that forking suspend.sf.net code
> is relatively easy; so even if we disagree about coding style of the
> userland parts, I can't veto it or something. And given that your only
> problem is including all the possible features, I probably will not
> have reason to stop you or something -- having all the features is
> okay in userland).

I don't want to fork anything. I didn't fork swsusp to start with, and I don't 
want to start forking things now. (If you want to debate that point, can you 
check the mailing list archives on Sourceforge, Berlios and suspend2.net 
first? You'll find that I just carried on where Florent left off).

> Now... switching to uswsusp kernel parts will make it slightly harder
> to install in the short term (messing with initrd). OTOH there's at
> least _chance_ to get to the point where suspend "just works" in
> Linux, in the long term...
>
> (Of course, you can just ignore this and keep maintaining out-of-tree
> suspend2. We'll also get to the point where it "just works"... it will
> just take a little longer.)

With your current design, I don't see how you're ever going to get to the 
level of functionality that Suspend2 has. I'm of course thinking of a full 
image of memory (although Rafael's patch a while back looked hopeful there) 
and support for other-than-just-one-swap-partition.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Avuton Olrich]

On 7/7/06, Pavel Machek <pavel@ucw.cz> wrote:
> Now... switching to uswsusp kernel parts will make it slightly harder
> to install in the short term (messing with initrd). OTOH there's at
> least _chance_ to get to the point where suspend "just works" in
> Linux, in the long term...

Long term being the key words. When will uswsusp be concidered 'rock
solid'? 2008+? Suspend2 is rock solid _today_. Imagine a world where
Linux drivers were as reliable as swsusp (granted I tried to get
uswsusp working and I gave up before messing with the initrd stuff).
I'm not even talking about all the extra features of Suspend2.

Maybe it's worth thinking about at least helping it get into -mm
before complaining about lack of testing Suspend2 has had. Sounds like
people are willing to do the work it would take to get it in, it
appears there is no vehicle at this point.
-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Bojan Smojver]

On Sat, 2006-07-08 at 02:28 +0200, Pavel Machek wrote:

> uswsusp makes suspend2 obsolete, and suspend2 now looks
> misdesigned. It puts too much stuff into the kernel, you know that
> already.

In order for uswsusp to make Suspend2 obsolete, it would have to *at
least* support what Suspend2 does. Unfortunately, that isn't the case
right now.

When can we expect all that in uswsusp?

-- 
Bojan

Re: uswsusp history lesson

[Jan Rychter]

>>>>> "Pavel" == Pavel Machek <pavel@ucw.cz> writes:
 Pavel> Hi!
 >> > > > So what Pavel wants can be translated as 'please use already
 >> > > > merged code, it can already do what you want without further
 >> > > > changing kernel'.
 >> > >
 >> > > Like we'd want to use unreviewed, extremely new and risky code
 >> > > for something that happily destroy filesystems.
 >> >
 >> > You can either use suspend2 (14000 lines of unreviewed kernel
 >> > code, old) or uswsusp (~500 lines of reviewed kernel code, ~2000
 >> > lines of unreviewed userspace code, new).
 >>
 >> I was going to keep quiet, but I have to say this: If Suspend2 can
 >> rightly be called unreviewed code, it's only because you've been too
 >> busy flaming etc to give it serious review. Personally, though, I
 >> don't think it's right

 Pavel> I really looked at suspend2 hard, year or so ago, when I was
 Pavel> pretty tired of the flamewars. At that point I decided it is way
 Pavel> too big to be acceptable to mainline, and got that crazy idea
 Pavel> about uswsusp, that surprisingly worked out at the end.

I hate these kinds of discussions, but since no one else did, I'm going
to say this very openly: I don't think you should be the one "deciding"
this. I don't know who and why named you the maintainer of all software
suspend solutions that might go into the mainline kernel, but facts are
that after at least two years of your maintainership (or is it more?):

  -- we still don't have working software suspend in the kernel (listen
     to the users),
  -- we have two implementations in the kernel (swsusp and uswsusp),
     none of which people are happy about,
  -- the implementation that many people are very happy with is being
     kept out because of your "decisions",

Again, those are facts. Forget about hand waving, concentrate on the
facts.

Finally, I personally would hold kernel maintainers to higher
standards. Not everyone has the right to say that something is "ugly"
without providing alternate solutions. Read some of Linus' E-mails: if
anyone has the right to wave hands without arguments it is him, but
still if he says something is ugly, he always provides a better
solution, sometimes also implementing it. And it works.

Re-stating the obvious: I'd like to see a maintainer of software suspend
that produces a working software suspend implementation.

I think most kernel developers underestimate how crucially important
suspend is for notebook users. It is the lifeblood of a notebook user's
life. Unless you develop the kernel and reboot your machine regularly,
you want a stable system that you can suspend and resume at any time,
reliably and predictably. This is way more important than new
schedulers or faster filesystems. It's about basic stability.

I know several people who got tired of the constant fight to keep the
machine running and switched to a Mac. I'm about to do the same as well.

As I don't expect any new arguments to appear in this thread
(unfortunately), and as I expect only more hand-waving from your side, I
won't be bothering you all anymore. EOT from my side.

--J.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Bojan Smojver]

On Sat, 2006-07-08 at 11:11 +0200, Jan Rychter wrote:

> I hate these kinds of discussions, but since no one else did, I'm going
> to say this very openly: I don't think you should be the one "deciding"
> this.

ACK.

Given that:

- this tie is permanent due to fundamental design disagreements

- swsusp, uswsusp and Suspend2 can coexist in the same tree

- Nigel has a track record of excellent support for his code

Why not make another kernel subsystem (Suspend2) and make Nigel
maintainer of it? Then all this nonsense can stop and distributions and
users can pick what they really want.

Andrew? Linus?

-- 
Bojan

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Rafael J. Wysocki]

Hi,

On Saturday 08 July 2006 05:42, Nigel Cunningham wrote:
> On Saturday 08 July 2006 10:28, Pavel Machek wrote:
> > I really looked at suspend2 hard, year or so ago, when I was pretty
> > tired of the flamewars. At that point I decided it is way too big to
> > be acceptable to mainline, and got that crazy idea about uswsusp, that
> > surprisingly worked out at the end.
> >
> > uswsusp makes suspend2 obsolete, and suspend2 now looks
> > misdesigned. It puts too much stuff into the kernel, you know that
> > already.
> 
> No, I don't. From my point of view, uswsusp is misdesigned, but suspend2 
> isn't. Suspend2 keeps the stuff that ought to be done by the kernel in the 
> kernel. It doesn't shift data out to userspace, only to copy it straight back 
> to the kernel for I/O. It will keep working even if userspace crashes and 
> burns. It leverages support for compression and encryption that's already in 
> the kernel. It does a real image of memory, not a half-pie attempt that 
> causes lots of faulting of pages etc post-resume.

I must say I completely disagree with the last sentence here.  AFAICT,
suspend2 does the following:
a) save LRU pages in the hope they won't be accesses after the system
has been snapshotted,
b) create the memory snapshot using the, now saved, LRU pages as additional
storage,
c) save the snapshot image created in b).

There are two problems here.  First, actually we are not sure if using LRU
pages as additional storage in b) is correct.  At least I've not seen any
argument supporting this except for "it has been tested for a long time
and nobody's reported any problems with it".  Second, in fact suspend2
saves two images, one consisting of LRU pages only and the second consisting
of the rest of memory.  Moreover, extra care must be taken while saving
LRU pages so that they don't get corrupted in the process and this makes
things quite complicated.

However, if we are sure that we can use LRU pages as additional storage in
b), they just can be included in the memory image without copying
and we only need some extra room for the other data and code.
If LRU pages take 50% of memory, this would allow us to create
a signle snapshot image as big as 75% of RAM (on x86_64).  IMO the
remaining 25% are not worth the increased complexity of suspend2,
especially that on 1 GB machine 75% of RAM is too much to save
for performance reasons (ie. the extra time you save by making the
system more responsive after resume is lost for saving and restoring
the image, even if compression is used).

Furthermore, I tried to measure how much time would actually be saved if
the images were greater than 50% of RAM (current swsusp's limit) and it
turned out to be 10% at the very last, with compression (on a 256MB box
with PII).

> If there's any misdesign in Suspend2, it's that I haven't made it a special
> case of checkpointing. But, of course, there's no support for checkpointing
> in the rest of the kernel at the moment anyway.
> 
> > From your point of view, uswsusp is misdesigned, too. It is too damn
> > hard to install. There's no way it could survive as a standalone patch
> > -- the way suspend2 survives. Fortunately, from distro point of view,
> > being hard to install does not matter that much. Distros already have
> > their own initrds, etc. And in the long term, distros matter, and I'm
> > quite confident I can make 90% distributions ship uswsusp + its
> > userland; cleaner kernel code matters, too, and maybe you'll agree
> > that if you only look at the kernel parts, uswsusp looks nicer.
> 
> It looks simple, I agree. But that's only because it's doing the minimum 
> required.

Again, I don't agree with this statement.  Moreover uswsusp (gosh, I _hate_
this name) is being developed on a regular basis, so I think it'll be doing
a bit more in the future.

> > Now, you are asking me to review 14000 lines of code. That's quite a
> > lot of code, and you did not exactly make reviewer's life easy. Also
> > reviews usually stop at first "fatal" problem, and you still drive
> > user interface from kernel. (Yes, drawing is done in userland, but
> > core user interface code is still in kernel). That is "fatal".
> 
> I agree that I didn't do the best job of making the reviewer's life easy. But 
> let's give me some credit. I did all those patches because I genuinely 
> thought that's what was requested the last time I submitted patches for 
> review. I didn't like splitting up the files into all those patches - it was 
> a lot of work and took a lot of time. But I did it because I wanted to do 
> what was asked and wanted to do what was necessary to get a good 
> implementation into the vanilla kernel.
> 
> Frankly, I'd rather be working on improving drivers and helping implement the 
> run-time power management than working on getting Suspend2 merged. But for 
> now, this is the immediate task.

Why so?

> I don't know why you see the user interface code as a problem. All the kernel 
> is doing is telling the userspace program, via a netlink socket, what's going 
> on and receiving messages from the userspace program sometimes.
> 
> > (Greg mentioned /proc usage being "fatal", too).
> 
> > Now... moving user interface into userland, and removing /proc usage
> > are big tasks, do you agree? And they will mean lot of changes, and
> > lot of new testing.
> 
> Removing /proc isn't a big task. It will affect the hibernate script far more 
> that the kernel code. The user interface is already in userland.
> 
> > Perhaps at this point right solution is to just drop suspend2
> > codebase, and do it again, this time in userland? Kernel
> > infrastructure is already there, and even if you wanted to replace
> > [u]swsusp by suspend2, you have to understand how the old code
> > works. (Another point you may like is that forking suspend.sf.net code
> > is relatively easy; so even if we disagree about coding style of the
> > userland parts, I can't veto it or something. And given that your only
> > problem is including all the possible features, I probably will not
> > have reason to stop you or something -- having all the features is
> > okay in userland).
> 
> I don't want to fork anything. I didn't fork swsusp to start with, and I don't 
> want to start forking things now. (If you want to debate that point, can you 
> check the mailing list archives on Sourceforge, Berlios and suspend2.net 
> first? You'll find that I just carried on where Florent left off).
> 
> > Now... switching to uswsusp kernel parts will make it slightly harder
> > to install in the short term (messing with initrd). OTOH there's at
> > least _chance_ to get to the point where suspend "just works" in
> > Linux, in the long term...
> >
> > (Of course, you can just ignore this and keep maintaining out-of-tree
> > suspend2. We'll also get to the point where it "just works"... it will
> > just take a little longer.)
> 
> With your current design, I don't see how you're ever going to get to the 
> level of functionality that Suspend2 has. I'm of course thinking of a full 
> image of memory (although Rafael's patch a while back looked hopeful there) 
> and support for other-than-just-one-swap-partition.

These are two different points.

Actually, as I said above, as soon as we are _sure_ that LRU pages are not
touched after the memory has been snapshotted, my patch will be mergeable
and we'll get the ability to create bigger images without the added
complexity.  [Apart from the fact that the whole memory image on a box with
more that 512 MB of RAM wouldn't make much sense, IMHO.]  The _only_ thing
needed here is an argument which you have to provide anyway to show that
suspend2 does the right thing.

As far as the support for ordinary files, swap files, etc. is concerned,
there's nothing to worry about.  It's comming.

Greetings,
Rafael

Re: [Suspend2-devel] Re: uswsusp history lesson

[Arjan van de Ven]

On Sat, 2006-07-08 at 20:14 +1000, Bojan Smojver wrote:
> On Sat, 2006-07-08 at 11:11 +0200, Jan Rychter wrote:
> 
> > I hate these kinds of discussions, but since no one else did, I'm going
> > to say this very openly: I don't think you should be the one "deciding"
> > this.
> 
> ACK.
> 
> Given that:
> 
> - this tie is permanent due to fundamental design disagreements
> 
> - swsusp, uswsusp and Suspend2 can coexist in the same tree
> 
> - Nigel has a track record of excellent support for his code
> 
> Why not make another kernel subsystem (Suspend2) and make Nigel
> maintainer of it? Then all this nonsense can stop and distributions and
> users can pick what they really want.

ok now a counter voice, and I'm sure I'm not going to be popular by
saying this:

Multiple all-half-working implementations is insane. It means bugs don't
get fixed, it means there isn't going to be ANY implementation that is
good enough for a broad audience. People will just switch to another one
rather than reporting and causing even the most simple bugs to get
fixed. What is worse, these suspend systems will inevitable have
different requirements on the rest of the kernel, and will thus
complicate the heck out of it for the rest of the developers. This in
turn will make *all* implementations more fragile, and everyone loses.

Very often, choice is good. but for something this fundamental, it is
not. We also don't have 2 scsi layers for example.

Now as to which it should be; I believe whatever happens it has to be
simple and robust. No fancy shnazy GUI inside the kernel, but SIMPLE.
Including well a defined and portable set of requirements on the kernel
and drivers, and done such that driver people who don't know the fine
details, can still get their drivers right.

Greetings,
   Arjan van de Ven

Re: [Suspend2-devel] Re: uswsusp history lesson

[Bojan Smojver]

On Sat, 2006-07-08 at 12:41 +0200, Arjan van de Ven wrote:

> What is worse, these suspend systems will inevitable have
> different requirements on the rest of the kernel, and will thus
> complicate the heck out of it for the rest of the developers.

My (user level) understanding is that built in swsusp and Suspend2 use
the same (or almost the same) machinery in the rest of the kernel to do
the work. I'm sure Nigel, Pavel and others can confirm or deny this.

> No fancy shnazy GUI inside the kernel, but SIMPLE.

AFAIK, none of the solutions have GUI inside the kernel.

-- 
Bojan

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Pavel Machek]

Hi!

> >Now... switching to uswsusp kernel parts will make it slightly harder
> >to install in the short term (messing with initrd). OTOH there's at
> >least _chance_ to get to the point where suspend "just works" in
> >Linux, in the long term...
> 
> Long term being the key words. When will uswsusp be concidered 'rock
> solid'? 2008+? Suspend2 is rock solid _today_. Imagine a world where

uswsusp is probably going to be used for SUSE10.2, so it will have to
be solid at that point. And SUSE10.2 is going to be
end-of-2006/early-2007, IIRC.

> Linux drivers were as reliable as swsusp (granted I tried to get
> uswsusp working and I gave up before messing with the initrd stuff).

Can I get proper bug report?

> In order for uswsusp to make Suspend2 obsolete, it would have to *at
> least* support what Suspend2 does. Unfortunately, that isn't the case
> right now.

Suspend2 does not have all the features uswsusp has, and uswsusp does
not have all the features suspend2 has.

If you really miss some feature in uswsusp, please help us with
coding...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Bojan Smojver]

On Sat, 2006-07-08 at 12:38 +0200, Rafael J. Wysocki wrote:

> Actually, as I said above, as soon as we are _sure_ that LRU pages are not
> touched after the memory has been snapshotted, my patch will be mergeable
> and we'll get the ability to create bigger images without the added
> complexity.  [Apart from the fact that the whole memory image on a box with
> more that 512 MB of RAM wouldn't make much sense, IMHO.]  The _only_ thing
> needed here is an argument which you have to provide anyway to show that
> suspend2 does the right thing.
> 
> As far as the support for ordinary files, swap files, etc. is concerned,
> there's nothing to worry about.  It's comming.

This all sounds very encouraging. What's the rough timeframe for this?

-- 
Bojan

Re: [Suspend2-devel] Re: uswsusp history lesson

[Pavel Machek]

On Sat 2006-07-08 21:11:17, Bojan Smojver wrote:
> On Sat, 2006-07-08 at 12:41 +0200, Arjan van de Ven wrote:
> 
> > What is worse, these suspend systems will inevitable have
> > different requirements on the rest of the kernel, and will thus
> > complicate the heck out of it for the rest of the developers.
> 
> My (user level) understanding is that built in swsusp and Suspend2 use
> the same (or almost the same) machinery in the rest of the kernel to do
> the work. I'm sure Nigel, Pavel and others can confirm or deny this.

It is pretty similar, yes.

> > No fancy shnazy GUI inside the kernel, but SIMPLE.
> 
> AFAIK, none of the solutions have GUI inside the kernel.

Then you need to read suspend2 patch again.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: uswsusp history lesson

[Bojan Smojver]

On Sat, 2006-07-08 at 13:13 +0200, Pavel Machek wrote:

> Then you need to read suspend2 patch again.

Didn't Nigel already explain that the kernel only passes the messages to
userspace, but doesn't actually do any "painting"?

-- 
Bojan

Re: [Suspend2-devel] Re: uswsusp history lesson

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

Hi.

On Saturday 08 July 2006 21:13, Pavel Machek wrote:
> > AFAIK, none of the solutions have GUI inside the kernel.
>
> Then you need to read suspend2 patch again.

No. You do. The kernel code sends netlink messages to a userspace app. It 
doesn't know or care whether or how that app displays the messages. All it 
does is send the status, or if there's no userui, do some printks.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Hi.

On Saturday 08 July 2006 21:12, Pavel Machek wrote:
> Hi!
>
> > >Now... switching to uswsusp kernel parts will make it slightly harder
> > >to install in the short term (messing with initrd). OTOH there's at
> > >least _chance_ to get to the point where suspend "just works" in
> > >Linux, in the long term...
> >
> > Long term being the key words. When will uswsusp be concidered 'rock
> > solid'? 2008+? Suspend2 is rock solid _today_. Imagine a world where
>
> uswsusp is probably going to be used for SUSE10.2, so it will have to
> be solid at that point. And SUSE10.2 is going to be
> end-of-2006/early-2007, IIRC.
>
> > Linux drivers were as reliable as swsusp (granted I tried to get
> > uswsusp working and I gave up before messing with the initrd stuff).
>
> Can I get proper bug report?
>
> > In order for uswsusp to make Suspend2 obsolete, it would have to *at
> > least* support what Suspend2 does. Unfortunately, that isn't the case
> > right now.
>
> Suspend2 does not have all the features uswsusp has, and uswsusp does
> not have all the features suspend2 has.

Oh. You mean the rsa key thing?

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Pavel Machek]

Hi!

> > I really looked at suspend2 hard, year or so ago, when I was pretty
> > tired of the flamewars. At that point I decided it is way too big to
> > be acceptable to mainline, and got that crazy idea about uswsusp, that
> > surprisingly worked out at the end.
> >
> > uswsusp makes suspend2 obsolete, and suspend2 now looks
> > misdesigned. It puts too much stuff into the kernel, you know that
> > already.
> 
> No, I don't. From my point of view, uswsusp is misdesigned, but suspend2 
> isn't. Suspend2 keeps the stuff that ought to be done by the kernel in the 
> kernel. It doesn't shift data out to userspace, only to copy it straight back 
> to the kernel for I/O. It will keep working even if userspace crashes and 
> burns. 

Copying back and forth is not a problem (3GB/sec RAM bandwidth
vs. 50MB/sec disk bandwidth), and at least we do not have to add LZF
to kernel.

> > From your point of view, uswsusp is misdesigned, too. It is too damn
> > hard to install. There's no way it could survive as a standalone patch
> > -- the way suspend2 survives. Fortunately, from distro point of view,
> > being hard to install does not matter that much. Distros already have
> > their own initrds, etc. And in the long term, distros matter, and I'm
> > quite confident I can make 90% distributions ship uswsusp + its
> > userland; cleaner kernel code matters, too, and maybe you'll agree
> > that if you only look at the kernel parts, uswsusp looks nicer.
> 
> It looks simple, I agree. But that's only because it's doing the minimum 
> required.

Yes, and that's exactly how kernel design should work.

> > Now... switching to uswsusp kernel parts will make it slightly harder
> > to install in the short term (messing with initrd). OTOH there's at
> > least _chance_ to get to the point where suspend "just works" in
> > Linux, in the long term...
> >
> > (Of course, you can just ignore this and keep maintaining out-of-tree
> > suspend2. We'll also get to the point where it "just works"... it will
> > just take a little longer.)
> 
> With your current design, I don't see how you're ever going to get to the 
> level of functionality that Suspend2 has. I'm of course thinking of a full 
> image of memory (although Rafael's patch a while back looked hopeful there) 
> and support for other-than-just-one-swap-partition.

Rafael's code was nice hack, unfortunately noone was able to review
it, so it is on hold. (You'll have similar problems, BTW; that LRU
issues are really "interesting").

other-than-just-one-swap-partition is a weekend task for someone
motivated. (And not even dangerous to your data, given that we can do
checksums.) [Any volunteers? Given ammount of trafic in my inbox,
suspend is still interesting topic.]
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 10223 bytes --]

Hi.

On Saturday 08 July 2006 20:38, Rafael J. Wysocki wrote:
> Hi,
>
> On Saturday 08 July 2006 05:42, Nigel Cunningham wrote:
> > On Saturday 08 July 2006 10:28, Pavel Machek wrote:
> > > I really looked at suspend2 hard, year or so ago, when I was pretty
> > > tired of the flamewars. At that point I decided it is way too big to
> > > be acceptable to mainline, and got that crazy idea about uswsusp, that
> > > surprisingly worked out at the end.
> > >
> > > uswsusp makes suspend2 obsolete, and suspend2 now looks
> > > misdesigned. It puts too much stuff into the kernel, you know that
> > > already.
> >
> > No, I don't. From my point of view, uswsusp is misdesigned, but suspend2
> > isn't. Suspend2 keeps the stuff that ought to be done by the kernel in
> > the kernel. It doesn't shift data out to userspace, only to copy it
> > straight back to the kernel for I/O. It will keep working even if
> > userspace crashes and burns. It leverages support for compression and
> > encryption that's already in the kernel. It does a real image of memory,
> > not a half-pie attempt that causes lots of faulting of pages etc
> > post-resume.
>
> I must say I completely disagree with the last sentence here.  AFAICT,
> suspend2 does the following:
> a) save LRU pages in the hope they won't be accesses after the system
> has been snapshotted,
> b) create the memory snapshot using the, now saved, LRU pages as additional
> storage,
> c) save the snapshot image created in b).
>
> There are two problems here.  First, actually we are not sure if using LRU
> pages as additional storage in b) is correct.  At least I've not seen any
> argument supporting this except for "it has been tested for a long time
> and nobody's reported any problems with it".  Second, in fact suspend2
> saves two images, one consisting of LRU pages only and the second
> consisting of the rest of memory.  Moreover, extra care must be taken while
> saving LRU pages so that they don't get corrupted in the process and this
> makes things quite complicated.

LRU pages are only going to be modified if:

a) kswapd runs and frees some
b) memory allocation paths try to get memory freed.
c) Userspace processes with these LRU pages run.

We have kswapd frozen, hooks to stop other processes trying to free memory 
(yes, I'm going to switch to your method of taking the pages off the lists), 
and userspace processes are frozen or their pages are excluded from the list.

> However, if we are sure that we can use LRU pages as additional storage in
> b), they just can be included in the memory image without copying
> and we only need some extra room for the other data and code.
> If LRU pages take 50% of memory, this would allow us to create
> a signle snapshot image as big as 75% of RAM (on x86_64).  IMO the
> remaining 25% are not worth the increased complexity of suspend2,
> especially that on 1 GB machine 75% of RAM is too much to save
> for performance reasons (ie. the extra time you save by making the
> system more responsive after resume is lost for saving and restoring
> the image, even if compression is used).

It's only too slow on swsusp. With Suspend2, I regularly suspend 1GB images on 
both my desktop and laptop machines. I agree that it might be slower on a 
4200RPM laptop drive, but you also have to balance this against faulting the 
pages back in post resume (which will be slower because they're not 
compressed and contiguous then, though maybe not not as noticable if you're 
saving 75% of memory).

> Furthermore, I tried to measure how much time would actually be saved if
> the images were greater than 50% of RAM (current swsusp's limit) and it
> turned out to be 10% at the very last, with compression (on a 256MB box
> with PII).

I think you'll find that this depends very much on the kind of workload you 
have, and how you try to compare apples with apples. If you're running lots 
of memory intensive apps (say VMware with a couple of hundred meg allocated, 
Open Office writer, Kmail, a couple of terminals and so on - I'm just 
describing what I normally run), you'll miss that extra memory more.

> > If there's any misdesign in Suspend2, it's that I haven't made it a
> > special case of checkpointing. But, of course, there's no support for
> > checkpointing in the rest of the kernel at the moment anyway.
> >
> > > From your point of view, uswsusp is misdesigned, too. It is too damn
> > > hard to install. There's no way it could survive as a standalone patch
> > > -- the way suspend2 survives. Fortunately, from distro point of view,
> > > being hard to install does not matter that much. Distros already have
> > > their own initrds, etc. And in the long term, distros matter, and I'm
> > > quite confident I can make 90% distributions ship uswsusp + its
> > > userland; cleaner kernel code matters, too, and maybe you'll agree
> > > that if you only look at the kernel parts, uswsusp looks nicer.
> >
> > It looks simple, I agree. But that's only because it's doing the minimum
> > required.
>
> Again, I don't agree with this statement.  Moreover uswsusp (gosh, I _hate_
> this name) is being developed on a regular basis, so I think it'll be doing
> a bit more in the future.

I know how you feel about uswsusp :) That's why I tried to get suspend into 
use in it's place.

> > > Now, you are asking me to review 14000 lines of code. That's quite a
> > > lot of code, and you did not exactly make reviewer's life easy. Also
> > > reviews usually stop at first "fatal" problem, and you still drive
> > > user interface from kernel. (Yes, drawing is done in userland, but
> > > core user interface code is still in kernel). That is "fatal".
> >
> > I agree that I didn't do the best job of making the reviewer's life easy.
> > But let's give me some credit. I did all those patches because I
> > genuinely thought that's what was requested the last time I submitted
> > patches for review. I didn't like splitting up the files into all those
> > patches - it was a lot of work and took a lot of time. But I did it
> > because I wanted to do what was asked and wanted to do what was necessary
> > to get a good implementation into the vanilla kernel.
> >
> > Frankly, I'd rather be working on improving drivers and helping implement
> > the run-time power management than working on getting Suspend2 merged.
> > But for now, this is the immediate task.
>
> Why so?

Why the immediate task, or why would I prefer to work on other things? I'll 
assume the former. Because I like to finish one things before starting 
another, and I'm thinking Suspend2 isn't finished until it's merged. 
Developmentwise, I think it's finished - unless I want to go off in a new 
direction and start implementing checkpointing, but I have virtually zero 
impetus for that at the moment.

> > I don't know why you see the user interface code as a problem. All the
> > kernel is doing is telling the userspace program, via a netlink socket,
> > what's going on and receiving messages from the userspace program
> > sometimes.
> >
> > > (Greg mentioned /proc usage being "fatal", too).
> > >
> > > Now... moving user interface into userland, and removing /proc usage
> > > are big tasks, do you agree? And they will mean lot of changes, and
> > > lot of new testing.
> >
> > Removing /proc isn't a big task. It will affect the hibernate script far
> > more that the kernel code. The user interface is already in userland.
> >
> > > Perhaps at this point right solution is to just drop suspend2
> > > codebase, and do it again, this time in userland? Kernel
> > > infrastructure is already there, and even if you wanted to replace
> > > [u]swsusp by suspend2, you have to understand how the old code
> > > works. (Another point you may like is that forking suspend.sf.net code
> > > is relatively easy; so even if we disagree about coding style of the
> > > userland parts, I can't veto it or something. And given that your only
> > > problem is including all the possible features, I probably will not
> > > have reason to stop you or something -- having all the features is
> > > okay in userland).
> >
> > I don't want to fork anything. I didn't fork swsusp to start with, and I
> > don't want to start forking things now. (If you want to debate that
> > point, can you check the mailing list archives on Sourceforge, Berlios
> > and suspend2.net first? You'll find that I just carried on where Florent
> > left off).
> >
> > > Now... switching to uswsusp kernel parts will make it slightly harder
> > > to install in the short term (messing with initrd). OTOH there's at
> > > least _chance_ to get to the point where suspend "just works" in
> > > Linux, in the long term...
> > >
> > > (Of course, you can just ignore this and keep maintaining out-of-tree
> > > suspend2. We'll also get to the point where it "just works"... it will
> > > just take a little longer.)
> >
> > With your current design, I don't see how you're ever going to get to the
> > level of functionality that Suspend2 has. I'm of course thinking of a
> > full image of memory (although Rafael's patch a while back looked hopeful
> > there) and support for other-than-just-one-swap-partition.
>
> These are two different points.
>
> Actually, as I said above, as soon as we are _sure_ that LRU pages are not
> touched after the memory has been snapshotted, my patch will be mergeable
> and we'll get the ability to create bigger images without the added
> complexity.  [Apart from the fact that the whole memory image on a box with
> more that 512 MB of RAM wouldn't make much sense, IMHO.]  The _only_ thing
> needed here is an argument which you have to provide anyway to show that
> suspend2 does the right thing.
>
> As far as the support for ordinary files, swap files, etc. is concerned,
> there's nothing to worry about.  It's comming.

Great. It will be good to see that. Do you have some way around bmapping the 
files?

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Bojan Smojver]

On Sat, 2006-07-08 at 21:31 +1000, Nigel Cunningham wrote:

> It's only too slow on swsusp. With Suspend2, I regularly suspend 1GB images on 
> both my desktop and laptop machines. I agree that it might be slower on a 
> 4200RPM laptop drive, but you also have to balance this against faulting the 
> pages back in post resume (which will be slower because they're not 
> compressed and contiguous then, though maybe not not as noticable if you're 
> saving 75% of memory).

I'm one of those unlucky people with a 4200 RPM notebook drive, coupled
with a crappy P4 based Celeron CPU. By far, Suspend2 provides a better
user experience than swsusp, even when saving all of 700+ MB or RAM.

-- 
Bojan

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Pavel Machek]

Hi!

> > > Frankly, I'd rather be working on improving drivers and helping implement
> > > the run-time power management than working on getting Suspend2 merged.
...
> Developmentwise, I think it's finished - unless I want to go off in a new 

I'd say that suspend2 already done its job -- forced me to do
uswsusp. I do not think it is mergeable without major refactoring.

Helping with runtime power management would be more welcome than
resubmitting same code over and over. Good news is that you can now do
what you prefer :-).

> > As far as the support for ordinary files, swap files, etc. is concerned,
> > there's nothing to worry about.  It's comming.
> 
> Great. It will be good to see that. Do you have some way around bmapping the 
> files?

You mean "some way to go without bmapping" or "did you get bmapping to
work" ?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: uswsusp history lesson

[Arjan van de Ven]

On Sat, 2006-07-08 at 21:11 +1000, Bojan Smojver wrote:
> On Sat, 2006-07-08 at 12:41 +0200, Arjan van de Ven wrote:
> 
> > What is worse, these suspend systems will inevitable have
> > different requirements on the rest of the kernel, and will thus
> > complicate the heck out of it for the rest of the developers.
> 
> My (user level) understanding is that built in swsusp and Suspend2 use
> the same (or almost the same) machinery in the rest of the kernel to do
> the work.

so they're almost the same conceptually... That's even more reason to go
for one unified approach.

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]

'ello.

On Saturday 08 July 2006 22:52, Pavel Machek wrote:
> > > > Frankly, I'd rather be working on improving drivers and helping
> > > > implement the run-time power management than working on getting
> > > > Suspend2 merged.
> > Developmentwise, I think it's finished - unless I want to go off in a new
>
> I'd say that suspend2 already done its job -- forced me to do
> uswsusp. I do not think it is mergeable without major refactoring.

I'm sorry, Pavel, but it if uswsusp is going to be an acceptable replacement 
for Suspend2, it has to actually have the features suspend2 has implemented, 
not just have the promise of them appearing at some stage. Rafael is doing 
admirable work in that direction, but he's not there yet.

On the day when I feel like I can switch from suspend2 to swsusp with no loss, 
and am convinced that my users can do the same, I'll happily switch. I've 
said all along, I'm just a user who wanted to suspend. I'm still a user who 
wants to suspend. I'm not committed come hell or high water to getting 
Suspend2 merged. But I am committed to having a good, usable implementation 
that just works. If you can get there with uswsusp, feel free. In the 
meantime, though, I have an implementation that I and many other people are 
happy with and I'm not convinced that you will be able to do all you're 
promising, so I'll have a go at getting Suspend2 merged. If Andrew and Linus 
don't want it, well it's no biggy to keep maintaining it out of tree. I'll be 
saddened for the people who miss out in the meantime, but I'll still sleep at 
night.

> Helping with runtime power management would be more welcome than
> resubmitting same code over and over. Good news is that you can now do
> what you prefer :-).

> > > As far as the support for ordinary files, swap files, etc. is
> > > concerned, there's nothing to worry about.  It's comming.
> >
> > Great. It will be good to see that. Do you have some way around bmapping
> > the files?
>
> You mean "some way to go without bmapping" or "did you get bmapping to
> work" ?

Some way to go without bmapping. I'm assuming you're going to have to add some 
kernel code to at least do the bmapping. By the way, watch out for block 
sizes. Especially with XFS. It's the best test of whether your code is right 
because the blocksize XFS uses might not be the same as the underlying block 
device's blocksize.

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[Olivier Galibert]

On Sat, Jul 08, 2006 at 12:41:58PM +0200, Arjan van de Ven wrote:
> Very often, choice is good. but for something this fundamental, it is
> not. We also don't have 2 scsi layers for example.

We have 2 ide layers, 2 usb-storage drivers, 2 sound systems and we
have had 2 pcmcia subsystems and 2 usb subsystems.  At one point, it's
the only way to find out what will work out.  Suspend2 and uswsusp
have very different fundamental designs, and it's quite unclear at
that point which one is the right one.


> Including well a defined and portable set of requirements on the kernel
> and drivers, and done such that driver people who don't know the fine
> details, can still get their drivers right.

The polarisation that is going on has resulted in nobody caring about
that, sadly enough.  And in any case it's absolutely demented that
non-disk drivers could have so much of an influence on the stability
of suspend-to-disk.

  OG.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Arjan van de Ven]

On Sat, 2006-07-08 at 18:43 +0200, Olivier Galibert wrote:
> On Sat, Jul 08, 2006 at 12:41:58PM +0200, Arjan van de Ven wrote:
> > Very often, choice is good. but for something this fundamental, it is
> > not. We also don't have 2 scsi layers for example.
> 
> We have 2 ide layers, 2 usb-storage drivers, 2 sound systems and we
> have had 2 pcmcia subsystems and 2 usb subsystems. 

well not sure about all of them... but it sucks.

Just take the alsa/OSS case. It's taken Adrian Bunk a LOT of effort to
get people to report bugs against alsa; unless you threaten to remove
the other driver they just won't and switch to the other driver. On the
one hand, that is choice. On the other, it's BAD. The user experience is
BAD. It means we end up with 2 half arsed cases (since the OSS driver
doesn't do other things) instead of one quite good one.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Arjan van de Ven]

On Sat, 2006-07-08 at 09:42 -0700, Sunil Kumar wrote:
>         Multiple all-half-working implementations is insane. It means
>         bugs don't
>         get fixed, it means there isn't going to be ANY implementation
>         that is 
>         good enough for a broad audience. People will just switch to
>         another one
>         rather than reporting and causing even the most simple bugs to
>         get
> 
> you are afraid nobody is going to use uswsusp (because it doesn't work
> or is not useful) and not going to report any bugs against it, and it
> will cease to exist over time. I think that is very good. Survival of
> the good. The winner will be decided by users automatically. Not by
> someone who 


note that I'm not picking sides. I don't care which ego gets to win.
What do care about that Linux ends up with a good implementation,
whatever that is. I have no idea is uswsusp will make it (in fact it
feels fragile to me, but then again all sw suspend implementations
including swsusp2 feel fragile to me). But for crying out loud

PICK ONE AND MAKE IT GOOD.

Bang heads together. Go for beer at OLS. I don't care how, but anything
to prevent the insane thing of having multiple half working
implementations.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Alon Bar-Lev]

On 7/8/06, Arjan van de Ven <arjan@infradead.org> wrote:
> Just take the alsa/OSS case. It's taken Adrian Bunk a LOT of effort to
> get people to report bugs against alsa; unless you threaten to remove
> the other driver they just won't and switch to the other driver. On the
> one hand, that is choice. On the other, it's BAD. The user experience is
> BAD. It means we end up with 2 half arsed cases (since the OSS driver
> doesn't do other things) instead of one quite good one.

Well...
OSS->swsusp
ALSA->Suspend2

Merge them both, and see which wins.
Anyway... Unlike the ALSA case, people opens bugs on suspen2 (The new
system) and not on swsusp, since Nigel is much more receptive, and
because of the large user community suspend2 works much better.

Pavel and Refael beg people to open bugs agains swsusp/uswsusp... But
people prefers to solve issues of the out-of-kernel solution...  The
process is as follows:

Try swsusp->It does not work/Not suited->Try suspend2->Works/does
not->Get support from suspend2->Suspend2 works->Suspend2 better->User
happy.

Best Regards,
Alon Bar-Lev.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Alan Cox]

Ar Sad, 2006-07-08 am 18:43 +0200, ysgrifennodd Olivier Galibert:
> On Sat, Jul 08, 2006 at 12:41:58PM +0200, Arjan van de Ven wrote:
> > Very often, choice is good. but for something this fundamental, it is
> > not. We also don't have 2 scsi layers for example.
> 
> We have 2 ide layers, 2 usb-storage drivers, 2 sound systems and we

(We've had effectively two SCSI layers before now btw when we've done
transitions from old_eh to new_eh)

> have had 2 pcmcia subsystems and 2 usb subsystems.  At one point, it's
> the only way to find out what will work out.  Suspend2 and uswsusp
> have very different fundamental designs, and it's quite unclear at
> that point which one is the right one.

I'd like to see this cleared up at OLS/Kernel summit. 

Alan

Re: [Suspend2-devel] Re: uswsusp history lesson

[Olivier Galibert]

On Sat, Jul 08, 2006 at 06:47:26PM +0200, Arjan van de Ven wrote:
> On Sat, 2006-07-08 at 18:43 +0200, Olivier Galibert wrote:
> > On Sat, Jul 08, 2006 at 12:41:58PM +0200, Arjan van de Ven wrote:
> > > Very often, choice is good. but for something this fundamental, it is
> > > not. We also don't have 2 scsi layers for example.
> > 
> > We have 2 ide layers, 2 usb-storage drivers, 2 sound systems and we
> > have had 2 pcmcia subsystems and 2 usb subsystems. 
> 
> well not sure about all of them... but it sucks.

- drivers/ide vs. Alan's libata work
- usb-storage vs. ub
- oss vs. alsa

And for the old ones:
- pcmcia-cs vs. Linus' yenta code
- the old usb stuff vs. Linus' rewrite

And I've forgottem v4l1 vs. v4l2 too.

> Just take the alsa/OSS case. It's taken Adrian Bunk a LOT of effort to
> get people to report bugs against alsa; unless you threaten to remove
> the other driver they just won't and switch to the other driver.

You're forgetting some inconvenient facts about alsa though:

- at least for a long while, they didn't care about compatibility
  between versions

- the interface is atrocious (shared library several orders of
  magnitude more complex than necessary, because KISS is not cool
  enough)

- the oss interface compatiblity has always been and still is
  considered a second class citizen

If the gpl-ification of the full OSS system had happened much earlier,
ALSA would have been crushed under its own weight by now.

  OG.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Arjan van de Ven]

On Sat, 2006-07-08 at 19:49 +0200, Olivier Galibert wrote:
> On Sat, Jul 08, 2006 at 06:47:26PM +0200, Arjan van de Ven wrote:
> > On Sat, 2006-07-08 at 18:43 +0200, Olivier Galibert wrote:
> > > On Sat, Jul 08, 2006 at 12:41:58PM +0200, Arjan van de Ven wrote:
> > > > Very often, choice is good. but for something this fundamental, it is
> > > > not. We also don't have 2 scsi layers for example.
> > > 
> > > We have 2 ide layers, 2 usb-storage drivers, 2 sound systems and we
> > > have had 2 pcmcia subsystems and 2 usb subsystems. 
> > 
> > well not sure about all of them... but it sucks.
> 
> - drivers/ide vs. Alan's libata work
> - usb-storage vs. ub
> - oss vs. alsa
> 
> And for the old ones:
> - pcmcia-cs vs. Linus' yenta code
> - the old usb stuff vs. Linus' rewrite
> 
> And I've forgottem v4l1 vs. v4l2 too.

you're giving a nice list of "technology A obsoletes technology B".
That's fine. It's also an entirely different situation.

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Rafael J. Wysocki]

On Saturday 08 July 2006 13:13, Bojan Smojver wrote:
> On Sat, 2006-07-08 at 12:38 +0200, Rafael J. Wysocki wrote:
> 
> > Actually, as I said above, as soon as we are _sure_ that LRU pages are not
> > touched after the memory has been snapshotted, my patch will be mergeable
> > and we'll get the ability to create bigger images without the added
> > complexity.  [Apart from the fact that the whole memory image on a box with
> > more that 512 MB of RAM wouldn't make much sense, IMHO.]  The _only_ thing
> > needed here is an argument which you have to provide anyway to show that
> > suspend2 does the right thing.
> > 
> > As far as the support for ordinary files, swap files, etc. is concerned,
> > there's nothing to worry about.  It's comming.
> 
> This all sounds very encouraging. What's the rough timeframe for this?

Probably a month, but that depends on how much time I will have.

Rafael

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Rafael J. Wysocki]

Hi,

On Saturday 08 July 2006 13:31, Nigel Cunningham wrote:
> On Saturday 08 July 2006 20:38, Rafael J. Wysocki wrote:
> > On Saturday 08 July 2006 05:42, Nigel Cunningham wrote:
> > > On Saturday 08 July 2006 10:28, Pavel Machek wrote:
> > > > I really looked at suspend2 hard, year or so ago, when I was pretty
> > > > tired of the flamewars. At that point I decided it is way too big to
> > > > be acceptable to mainline, and got that crazy idea about uswsusp, that
> > > > surprisingly worked out at the end.
> > > >
> > > > uswsusp makes suspend2 obsolete, and suspend2 now looks
> > > > misdesigned. It puts too much stuff into the kernel, you know that
> > > > already.
> > >
> > > No, I don't. From my point of view, uswsusp is misdesigned, but suspend2
> > > isn't. Suspend2 keeps the stuff that ought to be done by the kernel in
> > > the kernel. It doesn't shift data out to userspace, only to copy it
> > > straight back to the kernel for I/O. It will keep working even if
> > > userspace crashes and burns. It leverages support for compression and
> > > encryption that's already in the kernel. It does a real image of memory,
> > > not a half-pie attempt that causes lots of faulting of pages etc
> > > post-resume.
> >
> > I must say I completely disagree with the last sentence here.  AFAICT,
> > suspend2 does the following:
> > a) save LRU pages in the hope they won't be accesses after the system
> > has been snapshotted,
> > b) create the memory snapshot using the, now saved, LRU pages as additional
> > storage,
> > c) save the snapshot image created in b).
> >
> > There are two problems here.  First, actually we are not sure if using LRU
> > pages as additional storage in b) is correct.  At least I've not seen any
> > argument supporting this except for "it has been tested for a long time
> > and nobody's reported any problems with it".  Second, in fact suspend2
> > saves two images, one consisting of LRU pages only and the second
> > consisting of the rest of memory.  Moreover, extra care must be taken while
> > saving LRU pages so that they don't get corrupted in the process and this
> > makes things quite complicated.
> 
> LRU pages are only going to be modified if:
> 
> a) kswapd runs and frees some
> b) memory allocation paths try to get memory freed.
> c) Userspace processes with these LRU pages run.

Not only then, it appears.  Some of them my be modified due to
completions, timers, etc. and the modifications may be triggered
from interrupt context.  At least that's what Andrew told me last time
this was discussed and I just didn't have any good answer to that.

That's why the patch has not been applied.

> We have kswapd frozen, hooks to stop other processes trying to free memory 
> (yes, I'm going to switch to your method of taking the pages off the lists), 
> and userspace processes are frozen or their pages are excluded from the list.
> 
> > However, if we are sure that we can use LRU pages as additional storage in
> > b), they just can be included in the memory image without copying
> > and we only need some extra room for the other data and code.
> > If LRU pages take 50% of memory, this would allow us to create
> > a signle snapshot image as big as 75% of RAM (on x86_64).  IMO the
> > remaining 25% are not worth the increased complexity of suspend2,
> > especially that on 1 GB machine 75% of RAM is too much to save
> > for performance reasons (ie. the extra time you save by making the
> > system more responsive after resume is lost for saving and restoring
> > the image, even if compression is used).
> 
> It's only too slow on swsusp. With Suspend2, I regularly suspend 1GB images on 
> both my desktop and laptop machines. I agree that it might be slower on a 
> 4200RPM laptop drive, but you also have to balance this against faulting the 
> pages back in post resume (which will be slower because they're not 
> compressed and contiguous then, though maybe not not as noticable if you're 
> saving 75% of memory).
> 
> > Furthermore, I tried to measure how much time would actually be saved if
> > the images were greater than 50% of RAM (current swsusp's limit) and it
> > turned out to be 10% at the very last, with compression (on a 256MB box
> > with PII).
> 
> I think you'll find that this depends very much on the kind of workload you 
> have, and how you try to compare apples with apples. If you're running lots 
> of memory intensive apps (say VMware with a couple of hundred meg allocated, 
> Open Office writer, Kmail, a couple of terminals and so on - I'm just 
> describing what I normally run), you'll miss that extra memory more.

Well, I tried really hard to justify the patch that allowed swsusp to create
bigger images and 10% was the greatest speedup I could get out of it
and, let me repeat, _with_ compression and async I/O.  I tried to simulate
different workloads etc., but I couldn't get more than 10% speedup
(the biggest image I got was as big as 80% of RAM) - counting the time
from issuing the suspend command to getting back _responsive_ system
after resume.

> > > If there's any misdesign in Suspend2, it's that I haven't made it a
> > > special case of checkpointing. But, of course, there's no support for
> > > checkpointing in the rest of the kernel at the moment anyway.
> > >
> > > > From your point of view, uswsusp is misdesigned, too. It is too damn
> > > > hard to install. There's no way it could survive as a standalone patch
> > > > -- the way suspend2 survives. Fortunately, from distro point of view,
> > > > being hard to install does not matter that much. Distros already have
> > > > their own initrds, etc. And in the long term, distros matter, and I'm
> > > > quite confident I can make 90% distributions ship uswsusp + its
> > > > userland; cleaner kernel code matters, too, and maybe you'll agree
> > > > that if you only look at the kernel parts, uswsusp looks nicer.
> > >
> > > It looks simple, I agree. But that's only because it's doing the minimum
> > > required.
> >
> > Again, I don't agree with this statement.  Moreover uswsusp (gosh, I _hate_
> > this name) is being developed on a regular basis, so I think it'll be doing
> > a bit more in the future.
> 
> I know how you feel about uswsusp :) That's why I tried to get suspend into 
> use in it's place.
> 
> > > > Now, you are asking me to review 14000 lines of code. That's quite a
> > > > lot of code, and you did not exactly make reviewer's life easy. Also
> > > > reviews usually stop at first "fatal" problem, and you still drive
> > > > user interface from kernel. (Yes, drawing is done in userland, but
> > > > core user interface code is still in kernel). That is "fatal".
> > >
> > > I agree that I didn't do the best job of making the reviewer's life easy.
> > > But let's give me some credit. I did all those patches because I
> > > genuinely thought that's what was requested the last time I submitted
> > > patches for review. I didn't like splitting up the files into all those
> > > patches - it was a lot of work and took a lot of time. But I did it
> > > because I wanted to do what was asked and wanted to do what was necessary
> > > to get a good implementation into the vanilla kernel.
> > >
> > > Frankly, I'd rather be working on improving drivers and helping implement
> > > the run-time power management than working on getting Suspend2 merged.
> > > But for now, this is the immediate task.
> >
> > Why so?
> 
> Why the immediate task, or why would I prefer to work on other things? I'll 
> assume the former. Because I like to finish one things before starting 
> another, and I'm thinking Suspend2 isn't finished until it's merged. 
> Developmentwise, I think it's finished - unless I want to go off in a new 
> direction and start implementing checkpointing, but I have virtually zero 
> impetus for that at the moment.
> 
> > > I don't know why you see the user interface code as a problem. All the
> > > kernel is doing is telling the userspace program, via a netlink socket,
> > > what's going on and receiving messages from the userspace program
> > > sometimes.
> > >
> > > > (Greg mentioned /proc usage being "fatal", too).
> > > >
> > > > Now... moving user interface into userland, and removing /proc usage
> > > > are big tasks, do you agree? And they will mean lot of changes, and
> > > > lot of new testing.
> > >
> > > Removing /proc isn't a big task. It will affect the hibernate script far
> > > more that the kernel code. The user interface is already in userland.
> > >
> > > > Perhaps at this point right solution is to just drop suspend2
> > > > codebase, and do it again, this time in userland? Kernel
> > > > infrastructure is already there, and even if you wanted to replace
> > > > [u]swsusp by suspend2, you have to understand how the old code
> > > > works. (Another point you may like is that forking suspend.sf.net code
> > > > is relatively easy; so even if we disagree about coding style of the
> > > > userland parts, I can't veto it or something. And given that your only
> > > > problem is including all the possible features, I probably will not
> > > > have reason to stop you or something -- having all the features is
> > > > okay in userland).
> > >
> > > I don't want to fork anything. I didn't fork swsusp to start with, and I
> > > don't want to start forking things now. (If you want to debate that
> > > point, can you check the mailing list archives on Sourceforge, Berlios
> > > and suspend2.net first? You'll find that I just carried on where Florent
> > > left off).
> > >
> > > > Now... switching to uswsusp kernel parts will make it slightly harder
> > > > to install in the short term (messing with initrd). OTOH there's at
> > > > least _chance_ to get to the point where suspend "just works" in
> > > > Linux, in the long term...
> > > >
> > > > (Of course, you can just ignore this and keep maintaining out-of-tree
> > > > suspend2. We'll also get to the point where it "just works"... it will
> > > > just take a little longer.)
> > >
> > > With your current design, I don't see how you're ever going to get to the
> > > level of functionality that Suspend2 has. I'm of course thinking of a
> > > full image of memory (although Rafael's patch a while back looked hopeful
> > > there) and support for other-than-just-one-swap-partition.
> >
> > These are two different points.
> >
> > Actually, as I said above, as soon as we are _sure_ that LRU pages are not
> > touched after the memory has been snapshotted, my patch will be mergeable
> > and we'll get the ability to create bigger images without the added
> > complexity.  [Apart from the fact that the whole memory image on a box with
> > more that 512 MB of RAM wouldn't make much sense, IMHO.]  The _only_ thing
> > needed here is an argument which you have to provide anyway to show that
> > suspend2 does the right thing.
> >
> > As far as the support for ordinary files, swap files, etc. is concerned,
> > there's nothing to worry about.  It's comming.
> 
> Great. It will be good to see that. Do you have some way around bmapping the 
> files?

No, I don't.

Greetings,
Rafael

Re: [Suspend2-devel] Re: uswsusp history lesson

[Rafael J. Wysocki]

On Saturday 08 July 2006 18:50, Arjan van de Ven wrote:
> On Sat, 2006-07-08 at 09:42 -0700, Sunil Kumar wrote:
> >         Multiple all-half-working implementations is insane. It means
> >         bugs don't
> >         get fixed, it means there isn't going to be ANY implementation
> >         that is 
> >         good enough for a broad audience. People will just switch to
> >         another one
> >         rather than reporting and causing even the most simple bugs to
> >         get
> > 
> > you are afraid nobody is going to use uswsusp (because it doesn't work
> > or is not useful) and not going to report any bugs against it, and it
> > will cease to exist over time. I think that is very good. Survival of
> > the good. The winner will be decided by users automatically. Not by
> > someone who 
> 
> 
> note that I'm not picking sides. I don't care which ego gets to win.
> What do care about that Linux ends up with a good implementation,
> whatever that is. I have no idea is uswsusp will make it (in fact it
> feels fragile to me, but then again all sw suspend implementations
> including swsusp2 feel fragile to me). But for crying out loud
> 
> PICK ONE AND MAKE IT GOOD.
> 
> Bang heads together. Go for beer at OLS. I don't care how, but anything
> to prevent the insane thing of having multiple half working
> implementations.

I think everyone agrees with that.  However, the problem is we already have
two of them and one is out of the tree.  Each of them has its supporters who
believe their implementation of choice is "better" and want it to become
the Only One.  Unfortunately the implementations are not 100% mergeable for
technical reasons and the out-of-the-tree one is more feature-rich.

Now there seem to be two possible ways to go:
1) Drop the implementation that already is in the kernel and replace it with
the out-of-the-tree one.
2) Improve the one that already is in the kernel incrementally, possibly
merging some code from the out-of-the-tree implementation, so that it's as
feature-rich as the other one.

Apparently 1) is what Nigel is trying to make happen and 2) is what I'd like
to do.

Greetings,
Rafael

Re: [Suspend2-devel] Re: uswsusp history lesson

[grundig]

El Sat, 8 Jul 2006 20:01:30 +0300,
"Alon Bar-Lev" <alon.barlev@gmail.com> escribió:

> Anyway... Unlike the ALSA case, people opens bugs on suspen2 (The new
> system) and not on swsusp, since Nigel is much more receptive, and
> because of the large user community suspend2 works much better.

Pavel has been working to make suspend work as hard as Nigel and others,
don't pretend the contrary because it's not true. They fixed swsusp so
that now it works for me, and they're actively improving it (which is
why they still deserve their place in the MAINTAINERS file, if it was
undermaintained or uswsusp would be a really bad idea I could
understand it, but it's not the case) every day where it doesn't
works (just as Nigel with suspend2).

Re: [Suspend2-devel] Re: uswsusp history lesson

[Arjan van de Ven]

>  so that it's as
> feature-rich as the other one.

this is one of the things that bothers me.
"features features features"
lets first get the basics right and working.
Once we have that in tree for a release or two and it's really
reliable... THEN and only THEN work on adding features.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Rafael J. Wysocki]

On Saturday 08 July 2006 21:48, Sunil Kumar wrote:
> >
> > Now there seem to be two possible ways to go:
> > 1) Drop the implementation that already is in the kernel and replace it
> > with
> > the out-of-the-tree one.
> > 2) Improve the one that already is in the kernel incrementally, possibly
> > merging some code from the out-of-the-tree implementation, so that it's as
> > feature-rich as the other one.
> >
> > Apparently 1) is what Nigel is trying to make happen and 2) is what I'd
> > like
> > to do.
> 
> Is that really true, Nigel, that you want 1)?
> 
> Is it really impossible to have the third possbility of both the
> implementations in kernel at the same time?

Well, I'm not totally against that, at least as far as -mm is concerned,
but I meant "in the long run".

Greetings,
Rafael

Re: [Suspend2-devel] Re: uswsusp history lesson

[Alon Bar-Lev]

On 7/8/06, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> Well, I'm not totally against that, at least as far as -mm is concerned,
> but I meant "in the long run".

Hello,

The fact that you are against that does not cancel this option. There
are three of them...
But can you please explain why you against that?

Alon.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Pavel Machek]

Hi!

> >  so that it's as
> > feature-rich as the other one.
> 
> this is one of the things that bothers me.
> "features features features"
> lets first get the basics right and working.
> Once we have that in tree for a release or two and it's really
> reliable... THEN and only THEN work on adding features.

It is okay... we are pretty careful, and most of those features are in
userspace code. As long as code does not damage the image in progress
(and I believe we have checksum there), more features should not
really hurt.

Besides, that is what this flamefest is about. Nigel wants all those
features in kernel, claims it can not be done incrementally, and due
to the design, he's probably right. uswsusp can do most/all of them in
userspace.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: uswsusp history lesson

[Rafael J. Wysocki]

On Saturday 08 July 2006 22:13, Alon Bar-Lev wrote:
> On 7/8/06, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > Well, I'm not totally against that, at least as far as -mm is concerned,
> > but I meant "in the long run".
> 
> Hello,
> 
> The fact that you are against that does not cancel this option. There
> are three of them...
> But can you please explain why you against that?

I said I were not.

Rafael

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Pavel Machek]

Hi!

> > > > > Frankly, I'd rather be working on improving drivers and helping
> > > > > implement the run-time power management than working on getting
> > > > > Suspend2 merged.
> > > Developmentwise, I think it's finished - unless I want to go off in a new
> >
> > I'd say that suspend2 already done its job -- forced me to do
> > uswsusp. I do not think it is mergeable without major refactoring.
> 
> I'm sorry, Pavel, but it if uswsusp is going to be an acceptable replacement 
> for Suspend2, it has to actually have the features suspend2 has implemented, 
> not just have the promise of them appearing at some stage. Rafael is doing 
> admirable work in that direction, but he's not there yet.

If you trust Rafael can get the features you want... please help
him. It should be easier than another suspend2 resubmit...

> > > > As far as the support for ordinary files, swap files, etc. is
> > > > concerned, there's nothing to worry about.  It's comming.
> > >
> > > Great. It will be good to see that. Do you have some way around bmapping
> > > the files?
> >
> > You mean "some way to go without bmapping" or "did you get bmapping to
> > work" ?
> 
> Some way to go without bmapping. I'm assuming you're going to have to add some 
> kernel code to at least do the bmapping. By the way, watch out for block 
> sizes. Especially with XFS. It's the best test of whether your code is right 
> because the blocksize XFS uses might not be the same as the underlying block 
> device's blocksize.

Why is bmapping evil?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Pavel Machek]

Hi!

> > We have kswapd frozen, hooks to stop other processes trying to free memory 
> > (yes, I'm going to switch to your method of taking the pages off the lists), 
> > and userspace processes are frozen or their pages are excluded from the list.
> > 
> > > However, if we are sure that we can use LRU pages as additional storage in
> > > b), they just can be included in the memory image without copying
> > > and we only need some extra room for the other data and code.
> > > If LRU pages take 50% of memory, this would allow us to create
> > > a signle snapshot image as big as 75% of RAM (on x86_64).  IMO the
> > > remaining 25% are not worth the increased complexity of suspend2,
> > > especially that on 1 GB machine 75% of RAM is too much to save
> > > for performance reasons (ie. the extra time you save by making the
> > > system more responsive after resume is lost for saving and restoring
> > > the image, even if compression is used).
> > 
> > It's only too slow on swsusp. With Suspend2, I regularly suspend 1GB images on 
> > both my desktop and laptop machines. I agree that it might be
> > slower on a 

uswsusp is as fast as suspend2. It does same LZF compression.

> > > Furthermore, I tried to measure how much time would actually be saved if
> > > the images were greater than 50% of RAM (current swsusp's limit) and it
> > > turned out to be 10% at the very last, with compression (on a 256MB box
> > > with PII).
> > 
> > I think you'll find that this depends very much on the kind of workload you 
> > have, and how you try to compare apples with apples. If you're running lots 
> > of memory intensive apps (say VMware with a couple of hundred meg allocated, 
> > Open Office writer, Kmail, a couple of terminals and so on - I'm just 
> > describing what I normally run), you'll miss that extra memory more.

Do you think you could get some repeatable benchmark for Rafael? He
worked quite hard on feature only to find out it makes little difference...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: uswsusp history lesson

[Alan Cox]

Ar Sad, 2006-07-08 am 19:49 +0200, ysgrifennodd Olivier Galibert:
> If the gpl-ification of the full OSS system had happened much earlier,
> ALSA would have been crushed under its own weight by now.

The "free" OSS was superior to the proprietary one in pretty much every
respect by the time ALSA had really got beyond being a neat alternative
driver for a couple of chips.

So no I don't think so. ALSA still needs more dieting but the OSS API
really didnt do the job.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

Hi.

On Sunday 09 July 2006 05:48, Sunil Kumar wrote:
> > Now there seem to be two possible ways to go:
> > 1) Drop the implementation that already is in the kernel and replace it
> > with
> > the out-of-the-tree one.
> > 2) Improve the one that already is in the kernel incrementally, possibly
> > merging some code from the out-of-the-tree implementation, so that it's
> > as feature-rich as the other one.
> >
> > Apparently 1) is what Nigel is trying to make happen and 2) is what I'd
> > like
> > to do.
>
> Is that really true, Nigel, that you want 1)?

I would be happy for suspend2 and swsusp to coexist for at least at while. 
That's why I've made suspend2 play nicely with swsusp ever since I ported it 
to 2.6.

> Is it really impossible to have the third possbility of both the
> implementations in kernel at the same time? If Nigel has a patch against mm
> series, that means that he has taken care of all the conflicts. Are we
> missing something here?

I just about have one. I just have one issue (the removal of name_to_dev_t by 
klibc) to address. A really simple or short-term solution would be to re-add 
it, but I want to think the issue through more carefully first.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

Hi.

On Sunday 09 July 2006 07:04, Pavel Machek wrote:
> > Some way to go without bmapping. I'm assuming you're going to have to add
> > some kernel code to at least do the bmapping. By the way, watch out for
> > block sizes. Especially with XFS. It's the best test of whether your code
> > is right because the blocksize XFS uses might not be the same as the
> > underlying block device's blocksize.
>
> Why is bmapping evil?

I didn't mean it's evil. I just mean it's complicated and potentially 
confusing because the result of bmap needs to modified by the number of 
blocks per sector to get the right value to pass to bio_submit. Maybe you're 
more experienced in these things than me, so it will be simple for you, but 
it took a while for me to get right.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

On Sunday 09 July 2006 07:10, Pavel Machek wrote:
> > > It's only too slow on swsusp. With Suspend2, I regularly suspend 1GB
> > > images on both my desktop and laptop machines. I agree that it might be
> > > slower on a
>
> uswsusp is as fast as suspend2. It does same LZF compression.

I agree for uncompressed images - I tried timing the writing of the image 
yesterday. I'm not sure about LZF though, because I couldn't get it to 
resume. I'd be interested to see it really be as fast as suspend2 with 
compression.

> > > > Furthermore, I tried to measure how much time would actually be saved
> > > > if the images were greater than 50% of RAM (current swsusp's limit)
> > > > and it turned out to be 10% at the very last, with compression (on a
> > > > 256MB box with PII).
> > >
> > > I think you'll find that this depends very much on the kind of workload
> > > you have, and how you try to compare apples with apples. If you're
> > > running lots of memory intensive apps (say VMware with a couple of
> > > hundred meg allocated, Open Office writer, Kmail, a couple of terminals
> > > and so on - I'm just describing what I normally run), you'll miss that
> > > extra memory more.
>
> Do you think you could get some repeatable benchmark for Rafael? He
> worked quite hard on feature only to find out it makes little difference...

Sure, but it will mean more if all of the tests are run on the same system, so 
I'll have another go at getting uswsusp to resume, when I get the chance.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[Bojan Smojver]

On Sat, 2006-07-08 at 15:19 +0200, Arjan van de Ven wrote:

> so they're almost the same conceptually... That's even more reason to go
> for one unified approach.

I couldn't agree more. Of course, we should have a better of the two
in-kernel implementations: Suspend2. But that's the problem - it's not
going to happen.

-- 
Bojan

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Bojan Smojver]

On Sat, 2006-07-08 at 20:34 +0200, Rafael J. Wysocki wrote:

> Probably a month, but that depends on how much time I will have.

Nice. Thanks for the info.

-- 
Bojan

Re: [Suspend2-devel] Re: uswsusp history lesson

[Bojan Smojver]

On Sat, 2006-07-08 at 21:25 +0200, Rafael J. Wysocki wrote:

> Now there seem to be two possible ways to go:
> 1) Drop the implementation that already is in the kernel and replace it with
> the out-of-the-tree one.
> 2) Improve the one that already is in the kernel incrementally, possibly
> merging some code from the out-of-the-tree implementation, so that it's as
> feature-rich as the other one.
> 
> Apparently 1) is what Nigel is trying to make happen and 2) is what I'd like
> to do.

I didn't get the impression from 1) at all. If anything, Nigel has been
busy making Suspend2 use swsusp machinery *more*, not less as of
recently. If he wanted to drop swsusp completely, why would he do
something like that?

But, the confusing bit for me here is 2). Given that you're the man for
uswsusp, why would you want to keep any of the in-kernel
implementations? The only thing that crosses my mind right now is that
uswsusp may be a bit heavy on setup, so Linux distros/users that may not
have the luxury of doing all that would be left without a suspend/resume
solution. Is that why you want to keep an in-kernel implementation as
well? Or is there some other reason?

-- 
Bojan

Re: [Suspend2-devel] Re: uswsusp history lesson

[Pavel Machek]

On Sun 2006-07-09 09:46:06, Bojan Smojver wrote:
> On Sat, 2006-07-08 at 21:25 +0200, Rafael J. Wysocki wrote:
> 
> > Now there seem to be two possible ways to go:
> > 1) Drop the implementation that already is in the kernel and replace it with
> > the out-of-the-tree one.
> > 2) Improve the one that already is in the kernel incrementally, possibly
> > merging some code from the out-of-the-tree implementation, so that it's as
> > feature-rich as the other one.
> > 
> > Apparently 1) is what Nigel is trying to make happen and 2) is what I'd like
> > to do.
> 
> I didn't get the impression from 1) at all. If anything, Nigel has been
> busy making Suspend2 use swsusp machinery *more*, not less as of
> recently. If he wanted to drop swsusp completely, why would he do
> something like that?
> 
> But, the confusing bit for me here is 2). Given that you're the man for
> uswsusp, why would you want to keep any of the in-kernel
> implementations? The only thing that crosses my mind right now is that
> uswsusp may be a bit heavy on setup, so Linux distros/users that may not
> have the luxury of doing all that would be left without a suspend/resume
> solution. Is that why you want to keep an in-kernel implementation as
> well? Or is there some other reason?

swsusp/uswsusp share 75% or so of code, and we can't really drop
swsusp soon, because that would break existing setups. Warning
year-or-so ahead is needed to do such big changes. Plus you are quite
right n that "heavy to setup" thing.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Pavel Machek]

Hi!

> > > > It's only too slow on swsusp. With Suspend2, I regularly suspend 1GB
> > > > images on both my desktop and laptop machines. I agree that it might be
> > > > slower on a
> >
> > uswsusp is as fast as suspend2. It does same LZF compression.
> 
> I agree for uncompressed images - I tried timing the writing of the image 
> yesterday. I'm not sure about LZF though, because I couldn't get it to 
> resume. I'd be interested to see it really be as fast as suspend2 with 
> compression.

Is there any way to help you? I assume normal swsusp resumes okay so
it is not driver problem?

> > Do you think you could get some repeatable benchmark for Rafael? He
> > worked quite hard on feature only to find out it makes little difference...
> 
> Sure, but it will mean more if all of the tests are run on the same system, so 
> I'll have another go at getting uswsusp to resume, when I get the chance.

Thanks.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: uswsusp history lesson

[Pavel Machek]

Hi!

> > > Very often, choice is good. but for something this fundamental, it is
> > > not. We also don't have 2 scsi layers for example.
> > 
> > We have 2 ide layers, 2 usb-storage drivers, 2 sound systems and we
> 
> (We've had effectively two SCSI layers before now btw when we've done
> transitions from old_eh to new_eh)
> 
> > have had 2 pcmcia subsystems and 2 usb subsystems.  At one point, it's
> > the only way to find out what will work out.  Suspend2 and uswsusp
> > have very different fundamental designs, and it's quite unclear at
> > that point which one is the right one.
> 
> I'd like to see this cleared up at OLS/Kernel summit. 

Unless something very wrong happens, I'll be at OLS/Kernel summit.

...it is going to be interesting week. I expect apparmor flamefest,
and this... Any idea where to buy cheap asbestos underwear? :-)
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

Hi.

On Sunday 09 July 2006 09:54, Pavel Machek wrote:
> Hi!
>
> > > > > It's only too slow on swsusp. With Suspend2, I regularly suspend
> > > > > 1GB images on both my desktop and laptop machines. I agree that it
> > > > > might be slower on a
> > >
> > > uswsusp is as fast as suspend2. It does same LZF compression.
> >
> > I agree for uncompressed images - I tried timing the writing of the image
> > yesterday. I'm not sure about LZF though, because I couldn't get it to
> > resume. I'd be interested to see it really be as fast as suspend2 with
> > compression.
>
> Is there any way to help you? I assume normal swsusp resumes okay so
> it is not driver problem?

That's right. I'll see if I can figure it out tomorrow, Lord willing. I 
have /dev/snapshot in my initrd but it gives that prompt asking for the 
device name. By the way, will it sit there foreever, or does that have a 
timeout?

> > > Do you think you could get some repeatable benchmark for Rafael? He
> > > worked quite hard on feature only to find out it makes little
> > > difference...
> >
> > Sure, but it will mean more if all of the tests are run on the same
> > system, so I'll have another go at getting uswsusp to resume, when I get
> > the chance.
>
> Thanks.

No problem.

Nigel

-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

Hi.

On Sunday 09 July 2006 09:57, Pavel Machek wrote:
> Hi!
>
> > > > Very often, choice is good. but for something this fundamental, it is
> > > > not. We also don't have 2 scsi layers for example.
> > >
> > > We have 2 ide layers, 2 usb-storage drivers, 2 sound systems and we
> >
> > (We've had effectively two SCSI layers before now btw when we've done
> > transitions from old_eh to new_eh)
> >
> > > have had 2 pcmcia subsystems and 2 usb subsystems.  At one point, it's
> > > the only way to find out what will work out.  Suspend2 and uswsusp
> > > have very different fundamental designs, and it's quite unclear at
> > > that point which one is the right one.
> >
> > I'd like to see this cleared up at OLS/Kernel summit.
>
> Unless something very wrong happens, I'll be at OLS/Kernel summit.
>
> ...it is going to be interesting week. I expect apparmor flamefest,
> and this... Any idea where to buy cheap asbestos underwear? :-)

I won't be there, but I'm happy to answer any questions by email or irc if 
that will help.

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Pavel Machek]

Hi!

> > > > > > It's only too slow on swsusp. With Suspend2, I regularly suspend
> > > > > > 1GB images on both my desktop and laptop machines. I agree that it
> > > > > > might be slower on a
> > > >
> > > > uswsusp is as fast as suspend2. It does same LZF compression.
> > >
> > > I agree for uncompressed images - I tried timing the writing of the image
> > > yesterday. I'm not sure about LZF though, because I couldn't get it to
> > > resume. I'd be interested to see it really be as fast as suspend2 with
> > > compression.
> >
> > Is there any way to help you? I assume normal swsusp resumes okay so
> > it is not driver problem?
> 
> That's right. I'll see if I can figure it out tomorrow, Lord willing. I 
> have /dev/snapshot in my initrd but it gives that prompt asking for the 
> device name. By the way, will it sit there foreever, or does that have a 
> timeout?

AFAICT it will just sit there... Entering full path to resume device
should help at that point:

        while (stat(resume_dev_name, &stat_buf)) {
                printf("resume: Could not stat the resume device file.\n"
                        "\tPlease type in the file name to try again"
                        "\tor press ENTER to boot the system: ");
                fgets(resume_dev_name, MAX_STR_LEN - 1, stdin);
                n = strlen(resume_dev_name) - 1;
                if (n <= 0)
                        return ENOENT;
                if (resume_dev_name[n] == '\n')
                        resume_dev_name[n] = '\0';
        }

BTW the way I get this to work is very hacky: just force root
filesystem to be ext2, then boot with init=/bin/bash, and launch
resume manually. I guess I should prepare myself proper initrd...

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: uswsusp history lesson

[Bojan Smojver]

On Sun, 2006-07-09 at 01:53 +0200, Pavel Machek wrote:

> swsusp/uswsusp share 75% or so of code, and we can't really drop
> swsusp soon, because that would break existing setups. Warning
> year-or-so ahead is needed to do such big changes. Plus you are quite
> right n that "heavy to setup" thing.

Ah, right. Thanks for clearing that up.

So, the plan is that in about a year or so there won't be any completely
in-kernel suspend implementations, only uswsusp?

-- 
Bojan

Re: [Suspend2-devel] Re: uswsusp history lesson

[Olivier Galibert]

On Sat, Jul 08, 2006 at 10:46:29PM +0100, Alan Cox wrote:
> The "free" OSS was superior to the proprietary one in pretty much every
> respect by the time ALSA had really got beyond being a neat alternative
> driver for a couple of chips.
> 
> So no I don't think so. ALSA still needs more dieting but the OSS API
> really didnt do the job.

Ok.  The current API looks better, but I agree I don't know the exact
timings.  Using ALSA is still hell-on-earth though.  And the actual
kernel interface is quite puke-worthy.

  OG.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Pavel Machek]

On Sun 2006-07-09 10:18:58, Bojan Smojver wrote:
> On Sun, 2006-07-09 at 01:53 +0200, Pavel Machek wrote:
> 
> > swsusp/uswsusp share 75% or so of code, and we can't really drop
> > swsusp soon, because that would break existing setups. Warning
> > year-or-so ahead is needed to do such big changes. Plus you are quite
> > right n that "heavy to setup" thing.
> 
> Ah, right. Thanks for clearing that up.
> 
> So, the plan is that in about a year or so there won't be any completely
> in-kernel suspend implementations, only uswsusp?

No, that was not what I tried to say. Just now, swsusp looks pretty
small (~1000 lines), way too many people use it, and it is too handy
for debugging. So I'm not trying to kill it just now. When klibc gets
into mainline, and pretty much everyone switches to uswsusp, yes, it
will be possible to remove swsusp. For now I'm just trying to keep it
stable and not add features to it, so it is as easy to maintain as
possible.

First sign of swsusp going out is going to be /sys/power/resume
disappearing. It is really badly documented/dangerous hack, and if
your distro uses initrd, anyway.. well you should probably just use
swsusp. It would be nice to remove it in year or two.

I wanted to point out that delay between "okay, I want this gone" and
the code disappearing from kernel tarball is about a year.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: uswsusp history lesson

[Bojan Smojver]

On Sun, 2006-07-09 at 02:32 +0200, Pavel Machek wrote:

> I wanted to point out that delay between "okay, I want this gone" and
> the code disappearing from kernel tarball is about a year.

OK, so the period for this kind of solution(s) to completely go away is
even longer.

Which brings me to my point. Given that with my proposal you would have
zero involvement with Suspend2 code (i.e. you would not be obligated to
fix/touch/do anything in *any way*), why not give Nigel a go? The man is
obviously willing to do stuff on his own and it won't cost you anything.
And if it doesn't work out - well, though luck for Nigel.

So, how about it?

-- 
Bojan

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Rafael J. Wysocki]

On Sunday 09 July 2006 02:02, Nigel Cunningham wrote:
> Hi.
> 
> On Sunday 09 July 2006 09:54, Pavel Machek wrote:
> > Hi!
> >
> > > > > > It's only too slow on swsusp. With Suspend2, I regularly suspend
> > > > > > 1GB images on both my desktop and laptop machines. I agree that it
> > > > > > might be slower on a
> > > >
> > > > uswsusp is as fast as suspend2. It does same LZF compression.
> > >
> > > I agree for uncompressed images - I tried timing the writing of the image
> > > yesterday. I'm not sure about LZF though, because I couldn't get it to
> > > resume. I'd be interested to see it really be as fast as suspend2 with
> > > compression.
> >
> > Is there any way to help you? I assume normal swsusp resumes okay so
> > it is not driver problem?
> 
> That's right. I'll see if I can figure it out tomorrow, Lord willing. I 
> have /dev/snapshot in my initrd but it gives that prompt asking for the 
> device name. By the way, will it sit there foreever, or does that have a 
> timeout?

You also need to have /dev/<your_resume_partition_name> as well as
/etc/suspend.conf in your initrd.

Plaese create an initrd with 'make install-resume-initrd' (it will create
the 'resume-initrd' file in /boot and make a copy of the existing one, if any)
and see what's there.

Rafael

Re: [Suspend2-devel] Re: uswsusp history lesson

[Matthew Garrett]

On Sat, Jul 08, 2006 at 09:25:12PM +0200, Rafael J. Wysocki wrote:

> Now there seem to be two possible ways to go:
> 1) Drop the implementation that already is in the kernel and replace it with
> the out-of-the-tree one.

This would break existing interfaces to some extent, right? suspend2 
doesn't have the same set of tunables. I'm not sure whether this is 
something we especially care about, but it would potentially break some 
existing userland code.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [Suspend2-devel] Re: uswsusp history lesson

[Rafael J. Wysocki]

On Sunday 09 July 2006 03:05, Bojan Smojver wrote:
> On Sun, 2006-07-09 at 02:32 +0200, Pavel Machek wrote:
> 
> > I wanted to point out that delay between "okay, I want this gone" and
> > the code disappearing from kernel tarball is about a year.
> 
> OK, so the period for this kind of solution(s) to completely go away is
> even longer.
> 
> Which brings me to my point. Given that with my proposal you would have
> zero involvement with Suspend2 code (i.e. you would not be obligated to
> fix/touch/do anything in *any way*), why not give Nigel a go? The man is
> obviously willing to do stuff on his own and it won't cost you anything.

The problem is he _can't_ do it on his own if he wants the code merged,
because for this purpose some people have to review it, and that's not
only me or Pavel, but also architecture maintainers, memory management
maintainers, and probably some other people too.  Moreover, Nigel needs
to address the issues raised by the reviewers.

> And if it doesn't work out - well, though luck for Nigel.

Some people have reviewed some parts of suspend2 recently and there
were some comments to address.  Now it's up to Nigel to address them or not,
and that's only the tip of the iceberg.  It'll take quite some time to review
the entire suspend2 and address all of the issues that people may have with
it.  This is a long way to go, but I personally am not against doing it.

Now there's the separate problem that we have to share _some_ code.
To an absolute minimum, we have to share the freezer code and the
code that handles devices, because it's also shared by suspend-to-RAM.
The code that handles devices is already shared, but we also _have_ _to_
share the freezer code.  Therefore, as long as suspend2 adds some code
to the freezer, it's not even close to be considerable for merging.

The additional freezer code from suspend2 needs to be either merged or
dropped _first_, before we can even think of including the rest of suspend2
in -mm.

Greetings
Rafael

Re: [Suspend2-devel] Re: uswsusp history lesson

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

Hi.

On Sunday 09 July 2006 22:15, Matthew Garrett wrote:
> On Sat, Jul 08, 2006 at 09:25:12PM +0200, Rafael J. Wysocki wrote:
> > Now there seem to be two possible ways to go:
> > 1) Drop the implementation that already is in the kernel and replace it
> > with the out-of-the-tree one.
>
> This would break existing interfaces to some extent, right? suspend2
> doesn't have the same set of tunables. I'm not sure whether this is
> something we especially care about, but it would potentially break some
> existing userland code.

I don't want to go this way immediately, but if we did, it doesn't need to 
mean breakage for userland. Suspend2 could replace the tunables that swsusp 
uses, so it could be a transparent replacement for swsusp, assuming that the 
filewriter was turned off by default. (I say this because if the filewriter 
and swapwriter are both compiled in, the format for resume2 is

resume2=[swap|file]:/dev/<whatever><:offset>

But with only the swapwriter or only the filewriter, the "swap" or "file" is 
optional.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]

Hi.

On Sunday 09 July 2006 23:51, Rafael J. Wysocki wrote:
> On Sunday 09 July 2006 03:05, Bojan Smojver wrote:
> > On Sun, 2006-07-09 at 02:32 +0200, Pavel Machek wrote:
> > > I wanted to point out that delay between "okay, I want this gone" and
> > > the code disappearing from kernel tarball is about a year.
> >
> > OK, so the period for this kind of solution(s) to completely go away is
> > even longer.
> >
> > Which brings me to my point. Given that with my proposal you would have
> > zero involvement with Suspend2 code (i.e. you would not be obligated to
> > fix/touch/do anything in *any way*), why not give Nigel a go? The man is
> > obviously willing to do stuff on his own and it won't cost you anything.
>
> The problem is he _can't_ do it on his own if he wants the code merged,
> because for this purpose some people have to review it, and that's not
> only me or Pavel, but also architecture maintainers, memory management
> maintainers, and probably some other people too.  Moreover, Nigel needs
> to address the issues raised by the reviewers.
>
> > And if it doesn't work out - well, though luck for Nigel.
>
> Some people have reviewed some parts of suspend2 recently and there
> were some comments to address.  Now it's up to Nigel to address them or
> not, and that's only the tip of the iceberg.  It'll take quite some time to
> review the entire suspend2 and address all of the issues that people may
> have with it.  This is a long way to go, but I personally am not against
> doing it.
>
> Now there's the separate problem that we have to share _some_ code.
> To an absolute minimum, we have to share the freezer code and the
> code that handles devices, because it's also shared by suspend-to-RAM.
> The code that handles devices is already shared, but we also _have_ _to_
> share the freezer code.  Therefore, as long as suspend2 adds some code
> to the freezer, it's not even close to be considerable for merging.

If Suspend2 added code in a way that broke swsusp, I would agree. But it 
doesn't.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[Rafael J. Wysocki]

On Sunday 09 July 2006 23:06, Nigel Cunningham wrote:
]-- snip --[
> > Now there's the separate problem that we have to share _some_ code.
> > To an absolute minimum, we have to share the freezer code and the
> > code that handles devices, because it's also shared by suspend-to-RAM.
> > The code that handles devices is already shared, but we also _have_ _to_
> > share the freezer code.  Therefore, as long as suspend2 adds some code
> > to the freezer, it's not even close to be considerable for merging.
> 
> If Suspend2 added code in a way that broke swsusp, I would agree. But it 
> doesn't.

This is not a matter of any breakage or lack thereof.  The problem is that the
freezer is _not_ _an_ _swsusp-only_ _code_.  It is used by someone else too,
and having two different freezers in the tree would be _insane_, because too
many things depend on that.  This would be like having two different memory
management systems, but at a smaller scale.

As far as I'm concerned, we _must_ find a way to have _one_ common freezer,
before we can _think_ of anything more.  Still that's not even complicated,
because your freezer changes are quite well separeted, so please resubmit
them and we'll discuss them again.  Perhaps we'll be able to reach an
agreement on what's mergeable and what's not and why.  Then, I'll do my
best to get the mergeable stuff merged, and when it gets merged, you will
drop the non-mergeable freezer changes.  I hope this is fair enough.

Rafael

Re: [Suspend2-devel] Re: uswsusp history lesson

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

Hi.

On Monday 10 July 2006 07:36, Rafael J. Wysocki wrote:
> On Sunday 09 July 2006 23:06, Nigel Cunningham wrote:
> ]-- snip --[
>
> > > Now there's the separate problem that we have to share _some_ code.
> > > To an absolute minimum, we have to share the freezer code and the
> > > code that handles devices, because it's also shared by suspend-to-RAM.
> > > The code that handles devices is already shared, but we also _have_
> > > _to_ share the freezer code.  Therefore, as long as suspend2 adds some
> > > code to the freezer, it's not even close to be considerable for
> > > merging.
> >
> > If Suspend2 added code in a way that broke swsusp, I would agree. But it
> > doesn't.
>
> This is not a matter of any breakage or lack thereof.  The problem is that
> the freezer is _not_ _an_ _swsusp-only_ _code_.  It is used by someone else
> too, and having two different freezers in the tree would be _insane_,
> because too many things depend on that.  This would be like having two
> different memory management systems, but at a smaller scale.

Please don't start doing what Pavel does, imputing to me motives and ideas 
that are clearly false. You know that I don't want to have two freezer 
implementations - I've never suggested the idea or even thought of it until 
you suggested it. My desire all along has been to improve what's already 
there, and I still want to do that.

I'm sorry that I'm not submitting and resubmitting things as fast as you'd 
like. Please try to remember that I'm not a full time programmer. I'm working 
for Redhat one day a week and the congregation I serve four days a week. 
Anything I do beyond the one day is purely my time, and I have plenty of 
other things to do too. It's not, therefore, that I want to drag my heels. 
Rather, I simply don't have the time to get things done as quickly as you and 
Pavel seem to be able to.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[Rafael J. Wysocki]

On Sunday 09 July 2006 23:46, Nigel Cunningham wrote:
> On Monday 10 July 2006 07:36, Rafael J. Wysocki wrote:
> > On Sunday 09 July 2006 23:06, Nigel Cunningham wrote:
> > ]-- snip --[
> >
> > > > Now there's the separate problem that we have to share _some_ code.
> > > > To an absolute minimum, we have to share the freezer code and the
> > > > code that handles devices, because it's also shared by suspend-to-RAM.
> > > > The code that handles devices is already shared, but we also _have_
> > > > _to_ share the freezer code.  Therefore, as long as suspend2 adds some
> > > > code to the freezer, it's not even close to be considerable for
> > > > merging.

(1)

> > >
> > > If Suspend2 added code in a way that broke swsusp, I would agree. But it
> > > doesn't.
> >
> > This is not a matter of any breakage or lack thereof.  The problem is that
> > the freezer is _not_ _an_ _swsusp-only_ _code_.  It is used by someone else
> > too, and having two different freezers in the tree would be _insane_,
> > because too many things depend on that.  This would be like having two
> > different memory management systems, but at a smaller scale.
> 
> Please don't start doing what Pavel does, imputing to me motives and ideas 
> that are clearly false. You know that I don't want to have two freezer 
> implementations - I've never suggested the idea or even thought of it until 
> you suggested it.

I was only trying to explain what I meant in (1).  Please don't take it
personally, I'm doing my best to make technical points only.

> My desire all along has been to improve what's already  
> there, and I still want to do that.

Same here.

> I'm sorry that I'm not submitting and resubmitting things as fast as you'd 
> like. Please try to remember that I'm not a full time programmer. I'm working 
> for Redhat one day a week and the congregation I serve four days a week.

I'm not a full time programmer too.  Now I'm just having some more free
time than usually, that's all.

> Anything I do beyond the one day is purely my time, and I have plenty of 
> other things to do too. It's not, therefore, that I want to drag my heels. 
> Rather, I simply don't have the time to get things done as quickly as you and 
> Pavel seem to be able to.

I didn't mean I'd like you to submit/resubmit things quickly.  You'll submit
them when you're ready, be it in a week or in a month, or later.  It's all up
to you. :-)

Greetings,
Rafael

Re: [Suspend2-devel] Re: uswsusp history lesson

[Bojan Smojver]

Quoting "Rafael J. Wysocki" <rjw@sisk.pl>:

> The problem is he _can't_ do it on his own if he wants the code merged,
> because for this purpose some people have to review it, and that's not
> only me or Pavel, but also architecture maintainers, memory management
> maintainers, and probably some other people too.  Moreover, Nigel needs
> to address the issues raised by the reviewers.

Of course, of course. Nobody is going to merge anything until relevant  
maintainers approve. That's not what I proposed.

My point is something else. A few months back Pavel mentioned that  
he's thinking of developers more than users when it comes to Suspend2.  
In other words, he was concerned with maintenance of the thing. I'm  
also guessing nobody likes signing their name on something they have  
fundamental design beef with. All valid points, of course.

In order to avoid all this, my proposal introduces Nigel as the  
maintainer of Suspend2 code (i.e. *only* the non-shared bits with  
swsusp/uswsusp).

Given that Nigel:

- doesn't want to rip out/change neither swsusp nor uswsusp
- wants to share code as much as possible
- wants to fix things to be technically acceptable
- has shown to able to maintain Suspend2 codebase for users
- no swsusp/uswsup coder would have to worry about Suspend2 code  
beyond already shared bits they would worry about anyway

I think it would be appropriate to let him do so (once the initial  
technical issues are fixed).

The "your design sucks" argument between Pavel and Nigel is not likely  
to be resolved by more talk (this thread is quite appropriately called  
"history lesson" :-). These two have been at it for months now, with  
no resolution in sight. Yours truly also contributed by useless  
flaming from time to time ;-) No need for that any more.

However, Pavel is the one in the position of power here (being the  
maintainer), so I think he should, in the interest of users, decide to  
give Suspend2 a fair chance (after all those technical issues are  
addressed, of course), by letting Suspend2 be in the same position as  
swsusp or uswsusp - in other words, in the main tree (actually -mm, to  
start with, just as Nigel asked). And with my proposal Pavel and other  
swsusp/uswsusp coders, yourself included, would not have to spend any  
effort past reviewing the initial set of patches.

In the end, it's a win-win.

-- 
Bojan

Re: [Suspend2-devel] Re: uswsusp history lesson

[Jason Lunz]

ncunningham@linuxmail.org said:
> If Suspend2 added code in a way that broke swsusp, I would agree. But it=20
> doesn't.

That isn't true. I stopped using the suspend2 patches after they broke
the in-kernel suspend twice in the last year, since 2.6.14 or so. (The
first time I reported one of these bugs is here:
http://article.gmane.org/gmane.linux.swsusp.general/3243)

Before I stopped using suspend2, there was a 6-8 month period where I
could easily use both in-kernel swsusp and suspend2 on my laptop. I kept
using suspend2 because it was faster, but I eventually stopped because
it locked up the machine during suspend or crashed it during resume on
one out of every 20-30 tries (and the crashes weren't in some driver
- the backtrace always pointed down into the guts of suspend code).

In-kernel swsusp, on the other hand, aside from being slower, has never
crashed or frozen the machine. The same is true of the new uswsusp code,
which i'd say subjectively feels nearly as fast as suspend2 was, with
both using lzf compression.

Jason

Re: [Suspend2-devel] Re: uswsusp history lesson

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]

Hi.

On Monday 10 July 2006 13:57, Jason Lunz wrote:
> ncunningham@linuxmail.org said:
> > If Suspend2 added code in a way that broke swsusp, I would agree. But
> > it=20 doesn't.
>
> That isn't true. I stopped using the suspend2 patches after they broke
> the in-kernel suspend twice in the last year, since 2.6.14 or so. (The
> first time I reported one of these bugs is here:
> http://article.gmane.org/gmane.linux.swsusp.general/3243)

The switch to using the swsusp lowlevel code was a bit bumpy, and I do admit 
that I broke swsusp from time to time, but these are the exceptions (as you 
say), and the general design is such that they should be coexist. I'll freely 
admit that I don't regularly test swsusp, but I'm also not reguarly changing 
things that should break it.

> Before I stopped using suspend2, there was a 6-8 month period where I
> could easily use both in-kernel swsusp and suspend2 on my laptop. I kept
> using suspend2 because it was faster, but I eventually stopped because
> it locked up the machine during suspend or crashed it during resume on
> one out of every 20-30 tries (and the crashes weren't in some driver
> - the backtrace always pointed down into the guts of suspend code).

Did you report them to the list? I try to be responsive (although, again, I 
don't always succeed to the extent that I'd like.

> In-kernel swsusp, on the other hand, aside from being slower, has never
> crashed or frozen the machine. The same is true of the new uswsusp code,
> which i'd say subjectively feels nearly as fast as suspend2 was, with
> both using lzf compression.

Yeah, being much simpler does have its advantages, and Rafael has done a good 
job with the uswsusp code. Hopefully I'll get to test it properly soon.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[dirk husemann]

[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]

Rafael J. Wysocki wrote:
> On Saturday 08 July 2006 18:50, Arjan van de Ven wrote:
>   
>> [...]
>> PICK ONE AND MAKE IT GOOD.
>>
>> Bang heads together. Go for beer at OLS. I don't care how, but anything
>> to prevent the insane thing of having multiple half working
>> implementations.
>>     
>
> I think everyone agrees with that.  However, the problem is we already have
> two of them and one is out of the tree.  Each of them has its supporters who
> believe their implementation of choice is "better" and want it to become
> the Only One. 
hmm...not quite sure that the suspend2 ppl want it to become the only
one...we just want to have a fair playing field; that is, not a
situation where we are being told "my code is in the kernel, i like it
much better, work on my code or go away and play somewhere else" when we
have tried the code in the kernel, have found it to be lacking, and have
an alternative that appears to be working much better.
>  Unfortunately the implementations are not 100% mergeable for
> technical reasons and the out-of-the-tree one is more feature-rich.
>
> Now there seem to be two possible ways to go:
> 1) Drop the implementation that already is in the kernel and replace it with
> the out-of-the-tree one.
> 2) Improve the one that already is in the kernel incrementally, possibly
> merging some code from the out-of-the-tree implementation, so that it's as
> feature-rich as the other one.
>
> Apparently 1) is what Nigel is trying to make happen and 2) is what I'd like
> to do.
>   
again, i think, nigel is trying to get (3) accomplished:

3) get the out-of-the-tree code merged into the kernel and let
users/developers/distros decide.


    cheers,
    dirk


-- 
Dr Dirk Husemann, Pervasive Computing, IBM Research, Zurich Research Lab
	hud@zurich.ibm.com --- http://www.zurich.ibm.com/~hud/
       PGP key: http://www.zurich.ibm.com/~hud/contact/PGP
  PGP Fingerprint: 983C 48E7 0A78 A313 401C  C4AD 3C0A 278E 6431 A149
	     Email only authentic if signed with PGP key.

Appended to this email is an electronic signature attachment. You can
ignore it if your email program does not know how to verify such a
signature. If you'd like to learn more about this topic, www.gnupg.org
is a good starting point.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[dirk husemann]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

Arjan van de Ven wrote:
>>  so that it's as
>> feature-rich as the other one.
>>     
>
> this is one of the things that bothers me.
> "features features features"
> lets first get the basics right and working.
> Once we have that in tree for a release or two and it's really
> reliable... THEN and only THEN work on adding features.
>   
hmm...could it be that we "features, features, features" in suspend2
because nigel & co did get the basics right?

    cheers,
    dirk

-- 
Dr Dirk Husemann, Pervasive Computing, IBM Research, Zurich Research Lab
	hud@zurich.ibm.com --- http://www.zurich.ibm.com/~hud/
       PGP key: http://www.zurich.ibm.com/~hud/contact/PGP
  PGP Fingerprint: 983C 48E7 0A78 A313 401C  C4AD 3C0A 278E 6431 A149
	     Email only authentic if signed with PGP key.

Appended to this email is an electronic signature attachment. You can
ignore it if your email program does not know how to verify such a
signature. If you'd like to learn more about this topic, www.gnupg.org
is a good starting point.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[Arjan van de Ven]

On Mon, 2006-07-10 at 11:11 +0200, dirk husemann wrote:
> Arjan van de Ven wrote:
> >>  so that it's as
> >> feature-rich as the other one.
> >>     
> >
> > this is one of the things that bothers me.
> > "features features features"
> > lets first get the basics right and working.
> > Once we have that in tree for a release or two and it's really
> > reliable... THEN and only THEN work on adding features.
> >   
> hmm...could it be that we "features, features, features" in suspend2
> because nigel & co did get the basics right?

As I said... if that is the case then it'd be easy to first merge "the
right basics", get that solid, and THEN add the features. So far I've
not seen that happen.

Re: [Suspend2-devel] Re: uswsusp history lesson

[Pavel Machek]

Hi!

> > >>  so that it's as
> > >> feature-rich as the other one.
> > >>     
> > >
> > > this is one of the things that bothers me.
> > > "features features features"
> > > lets first get the basics right and working.
> > > Once we have that in tree for a release or two and it's really
> > > reliable... THEN and only THEN work on adding features.
> > >   
> > hmm...could it be that we "features, features, features" in suspend2
> > because nigel & co did get the basics right?
> 
> As I said... if that is the case then it'd be easy to first merge "the
> right basics", get that solid, and THEN add the features. So far I've
> not seen that happen.

Well.. Nigel claims his code can not be split into reasonable chunks.

I actually wanted to get a version without advanced features
(userspace splash, compression, encryption, plugins), but he claims it
is not possible. Rafael is trying to persuade him to split out at
least freezer out...
								Pavel
-- 
Thanks, Sharp!

Re: [Suspend2-devel] Re: uswsusp history lesson

[Thomas Tuttle]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

First, let me say, I've gotten both swsusp and suspend2 to work, but
I've had better luck with hardware under suspend2, and reading and
writing the image was faster under suspend2.

On July 10 at 05:18 EDT, Arjan van de Ven hastily scribbled:
> As I said... if that is the case then it'd be easy to first merge "the
> right basics", get that solid, and THEN add the features. So far I've
> not seen that happen.

So, you mean like merge just the freezer mods (if needed), and the
suspend2 core, and then add the encryption/compression/filewriter/userui
stuff separately?

That doesn't sound too unreasonable, if it's possible to separate them.

--Thomas Tuttle

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[Arjan van de Ven]

On Mon, 2006-07-10 at 08:45 -0400, Thomas Tuttle wrote:
> First, let me say, I've gotten both swsusp and suspend2 to work, but
> I've had better luck with hardware under suspend2, and reading and
> writing the image was faster under suspend2.
> 
> On July 10 at 05:18 EDT, Arjan van de Ven hastily scribbled:
> > As I said... if that is the case then it'd be easy to first merge "the
> > right basics", get that solid, and THEN add the features. So far I've
> > not seen that happen.
> 
> So, you mean like merge just the freezer mods (if needed), and the
> suspend2 core, and then add the encryption/compression/filewriter/userui
> stuff separately?

yes. If suspend2 core is really better, that should be an improvement
already, without the additional complexity of the
encryption/compression/etc stuff. Get that merged, get it out there,
once a lot more people use it there may also be a lot more bug reports,
which are easier to fix in a low complexity environment. When that is
done, the encryption/compression/etc can be merged incrementally and
reviewed incrementally, on top of a stable basis. 

When something is as tricky as suspend, the primary goal should be to
avoid complexity until things are stable. The suspend2 side of the house
seems to suggest the kernel.org state currently is not (I'm not going to
stick my hand in the hornest nest and agree or disagree), and if that's
indeed the case then just fixing that bit should be paramount, without
adding "unneeded" complexity at the same time.

This doesn't mean that I don't like any of those features. Don't get me
wrong there. It just means that I'm saying that adding those as a second
phase instead makes a whole lot of sense to me, just to keep the problem
clean. 

Re: [Suspend2-devel] Re: uswsusp history lesson

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

Hi.

On Monday 10 July 2006 20:02, Pavel Machek wrote:
> Hi!
>
> > > >>  so that it's as
> > > >> feature-rich as the other one.
> > > >
> > > > this is one of the things that bothers me.
> > > > "features features features"
> > > > lets first get the basics right and working.
> > > > Once we have that in tree for a release or two and it's really
> > > > reliable... THEN and only THEN work on adding features.
> > >
> > > hmm...could it be that we "features, features, features" in suspend2
> > > because nigel & co did get the basics right?
> >
> > As I said... if that is the case then it'd be easy to first merge "the
> > right basics", get that solid, and THEN add the features. So far I've
> > not seen that happen.
>
> Well.. Nigel claims his code can not be split into reasonable chunks.
>
> I actually wanted to get a version without advanced features
> (userspace splash, compression, encryption, plugins), but he claims it
> is not possible. Rafael is trying to persuade him to split out at
> least freezer out...

When did you ask for that? Perhaps I missed it.

The modularity is part of the basis of the redesign, so I couldn't easily 
remove that. Removing the compression and encryption support is trivial 
though (one file each, plus Makefile & Kconfig entries - no other 
modifications needed). Userspace splash - well, just don't compile and 
install that userspace component - suspend2 will keep working quite happily 
without any userspace app to do a nice display (it will still do printks, so 
you won't be flying completely blind).

As for the freezer, Rafael doesn't need to persuade me at all. I just need to 
find the time to do what he requested.

Regards,

Nigel
-- 
See http://www.suspend2.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[Pavel Machek]

Hi!

> > > As I said... if that is the case then it'd be easy to first merge "the
> > > right basics", get that solid, and THEN add the features. So far I've
> > > not seen that happen.
> >
> > Well.. Nigel claims his code can not be split into reasonable chunks.
> >
> > I actually wanted to get a version without advanced features
> > (userspace splash, compression, encryption, plugins), but he claims it
> > is not possible. Rafael is trying to persuade him to split out at
> > least freezer out...
> 
> When did you ask for that? Perhaps I missed it.

It was long time ago...

> The modularity is part of the basis of the redesign, so I couldn't easily 
> remove that. Removing the compression and encryption support is trivial 
> though (one file each, plus Makefile & Kconfig entries - no other 
> modifications needed). Userspace splash - well, just don't compile and 
> install that userspace component - suspend2 will keep working quite happily 
> without any userspace app to do a nice display (it will still do printks, so 
> you won't be flying completely blind).

Lets see the patches, then.

> As for the freezer, Rafael doesn't need to persuade me at all. I just need to 
> find the time to do what he requested.

Ok.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Suspend2-devel] Re: uswsusp history lesson

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

Hi.

On Tuesday 11 July 2006 09:22, Pavel Machek wrote:
> > The modularity is part of the basis of the redesign, so I couldn't easily
> > remove that. Removing the compression and encryption support is trivial
> > though (one file each, plus Makefile & Kconfig entries - no other
> > modifications needed). Userspace splash - well, just don't compile and
> > install that userspace component - suspend2 will keep working quite
> > happily without any userspace app to do a nice display (it will still do
> > printks, so you won't be flying completely blind).
>
> Lets see the patches, then.

They're basically what you already have - as I said, just ignore the 
compression and encryption files and a couple of lines in the Makefile and 
Kconfig changes. No modifications are needed to have suspend2 without a 
userspace user interface. That's the advantage of that modular design you 
don't like.

Regards,

Nigel
-- 
See http://www.suspend2.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]

Hi.

On Sunday 09 July 2006 04:52, Rafael J. Wysocki wrote:
> Well, I tried really hard to justify the patch that allowed swsusp to
> create bigger images and 10% was the greatest speedup I could get out of it
> and, let me repeat, _with_ compression and async I/O.  I tried to simulate
> different workloads etc., but I couldn't get more than 10% speedup (the
> biggest image I got was as big as 80% of RAM) - counting the time from
> issuing the suspend command to getting back _responsive_ system after
> resume.

Was that 10% speedup on suspend or resume, or both? With LZF, I see 
approximately double the speed with both reading and writing:

nigel@nigel:/usr/src$ sudo cat /sys/power/suspend2/debug_info
Suspend2 debugging info:
- SUSPEND core   : 2.2.7.2
- Kernel Version : 2.6.18-rc1
- Compiler vers. : 4.0
- Attempt number : 4
- Parameters     : 0 25 0 0 0 0
- Overall expected compression percentage: 0.
- Compressor is 'lzf'.
  Compressed 733736960 bytes into 349517344 (52 percent compression).
- Swapwriter active.
  Swap available for image: 244981 pages.
- Filewriter inactive.
- I/O speed: Write 79 MB/s, Read 77 MB/s.
- Extra pages    : -53 used/4000.

Without compression:

nigel@nigel:/usr/src$ sudo cat /sys/power/suspend2/debug_info
Suspend2 debugging info:
- SUSPEND core   : 2.2.7.2
- Kernel Version : 2.6.18-rc1
- Compiler vers. : 4.0
- Attempt number : 5
- Parameters     : 0 25 0 0 0 0
- Overall expected compression percentage: 0.
- Swapwriter active.
  Swap available for image: 244981 pages.
- Filewriter inactive.
- I/O speed: Write 39 MB/s, Read 38 MB/s.
- Extra pages    : -72 used/4000.

On resume, how are managing to keep the speed up? I implemented readahead of 
up to 2000 pages, only waiting on a page if we actually manage to submit the 
next 2000 pages for I/O and the page we're waiting on isn't yet complete. If 
you do something like that, how do you know when I/O is complete on the page 
you want?

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Suspend2-devel] Re: uswsusp history lesson

[Jason Lunz]

On Mon, Jul 10, 2006 at 04:20:30PM +1000, Nigel Cunningham wrote:
> The switch to using the swsusp lowlevel code was a bit bumpy, and I do admit 
> that I broke swsusp from time to time, but these are the exceptions (as you 
> say), and the general design is such that they should be coexist. I'll freely 
> admit that I don't regularly test swsusp, but I'm also not reguarly changing 
> things that should break it.

I would suggest testing swsusp before each suspend2 release. It's not
difficult at all to maintain a system that can suspend to disk using
either method, especially if you use something like Bernard's hibernate
scripts.

I would say that's especially important if you're posting the patches
for inclusion in mainline. It's simply not acceptible to merge patches
that break working in-kernel setups.

> Did you report them to the list? I try to be responsive (although, again, I 
> don't always succeed to the extent that I'd like.

Unfortunately, no. Because of the intermittency of the crashes, I was
usually on the road or in the middle of something else when a crash
happened, so I never captured any of the backtraces.

Jason

Re: [Suspend2-devel] Re: uswsusp history lesson

[Bojan Smojver]

On Tue, 2006-07-11 at 10:47 -0400, Jason Lunz wrote:

> I would suggest testing swsusp before each suspend2 release. It's not
> difficult at all to maintain a system that can suspend to disk using
> either method, especially if you use something like Bernard's hibernate
> scripts.

I think this is a great idea. When Suspend2 hits the -mm and the
mainline, all this should get a lot more testing, so problems will
surface more quickly.

-- 
Bojan

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Rafael J. Wysocki]

Hi,

On Tuesday 11 July 2006 14:45, Nigel Cunningham wrote:
> On Sunday 09 July 2006 04:52, Rafael J. Wysocki wrote:
> > Well, I tried really hard to justify the patch that allowed swsusp to
> > create bigger images and 10% was the greatest speedup I could get out of it
> > and, let me repeat, _with_ compression and async I/O.  I tried to simulate
> > different workloads etc., but I couldn't get more than 10% speedup (the
> > biggest image I got was as big as 80% of RAM) - counting the time from
> > issuing the suspend command to getting back _responsive_ system after
> > resume.
> 
> Was that 10% speedup on suspend or resume, or both? With LZF, I see 
> approximately double the speed with both reading and writing:

I was not referring to the speedup of writing and/or reading.

The exercise was to measure the time needed to suspend the system and get
it back in a responsive state.  I measured the time elapsed between triggering
the suspend and the moment at which I could switch between some applications
in X without any noticeable lag due to faulting in some pages (that is a bit
subjective, I must admit, but I was willing to show that bigger images make
substantial difference).

I tested uswsusp with compression (LZF) and two image sizes: 120 MB and
(IIRC) about 220 MB on a 256 MB box.  The result of the measurement for the
120 MB image has always been greater than for the 220 MB image, but the
difference has never been greater than 10%.

Greetings,
Rafael

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

Hi.

On Wednesday 12 July 2006 07:54, Rafael J. Wysocki wrote:
> Hi,
>
> On Tuesday 11 July 2006 14:45, Nigel Cunningham wrote:
> > On Sunday 09 July 2006 04:52, Rafael J. Wysocki wrote:
> > > Well, I tried really hard to justify the patch that allowed swsusp to
> > > create bigger images and 10% was the greatest speedup I could get out
> > > of it and, let me repeat, _with_ compression and async I/O.  I tried to
> > > simulate different workloads etc., but I couldn't get more than 10%
> > > speedup (the biggest image I got was as big as 80% of RAM) - counting
> > > the time from issuing the suspend command to getting back _responsive_
> > > system after resume.
> >
> > Was that 10% speedup on suspend or resume, or both? With LZF, I see
> > approximately double the speed with both reading and writing:
>
> I was not referring to the speedup of writing and/or reading.
>
> The exercise was to measure the time needed to suspend the system and get
> it back in a responsive state.  I measured the time elapsed between
> triggering the suspend and the moment at which I could switch between some
> applications in X without any noticeable lag due to faulting in some pages
> (that is a bit subjective, I must admit, but I was willing to show that
> bigger images make substantial difference).
>
> I tested uswsusp with compression (LZF) and two image sizes: 120 MB and
> (IIRC) about 220 MB on a 256 MB box.  The result of the measurement for the
> 120 MB image has always been greater than for the 220 MB image, but the
> difference has never been greater than 10%.

Ah ok. Are you sure you're getting that sort of throughput with LZF though - 
if you're not, you might be underestimating the advantage.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Rafael J. Wysocki]

On Wednesday 12 July 2006 00:01, Nigel Cunningham wrote:
> On Wednesday 12 July 2006 07:54, Rafael J. Wysocki wrote:
> > On Tuesday 11 July 2006 14:45, Nigel Cunningham wrote:
> > > On Sunday 09 July 2006 04:52, Rafael J. Wysocki wrote:
> > > > Well, I tried really hard to justify the patch that allowed swsusp to
> > > > create bigger images and 10% was the greatest speedup I could get out
> > > > of it and, let me repeat, _with_ compression and async I/O.  I tried to
> > > > simulate different workloads etc., but I couldn't get more than 10%
> > > > speedup (the biggest image I got was as big as 80% of RAM) - counting
> > > > the time from issuing the suspend command to getting back _responsive_
> > > > system after resume.
> > >
> > > Was that 10% speedup on suspend or resume, or both? With LZF, I see
> > > approximately double the speed with both reading and writing:
> >
> > I was not referring to the speedup of writing and/or reading.
> >
> > The exercise was to measure the time needed to suspend the system and get
> > it back in a responsive state.  I measured the time elapsed between
> > triggering the suspend and the moment at which I could switch between some
> > applications in X without any noticeable lag due to faulting in some pages
> > (that is a bit subjective, I must admit, but I was willing to show that
> > bigger images make substantial difference).
> >
> > I tested uswsusp with compression (LZF) and two image sizes: 120 MB and
> > (IIRC) about 220 MB on a 256 MB box.  The result of the measurement for the
> > 120 MB image has always been greater than for the 220 MB image, but the
> > difference has never been greater than 10%.
> 
> Ah ok. Are you sure you're getting that sort of throughput with LZF though - 
> if you're not, you might be underestimating the advantage.

Certainly I don't get that kind of speedup for writing.  For reading I do.

Greetings,
Rafael

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

Hi.

On Wednesday 12 July 2006 08:34, Rafael J. Wysocki wrote:
> On Wednesday 12 July 2006 00:01, Nigel Cunningham wrote:
> > On Wednesday 12 July 2006 07:54, Rafael J. Wysocki wrote:
> > > On Tuesday 11 July 2006 14:45, Nigel Cunningham wrote:
> > > > Was that 10% speedup on suspend or resume, or both? With LZF, I see
> > > > approximately double the speed with both reading and writing:
> > >
> > > I was not referring to the speedup of writing and/or reading.
> > >
> > > The exercise was to measure the time needed to suspend the system and
> > > get it back in a responsive state.  I measured the time elapsed between
> > > triggering the suspend and the moment at which I could switch between
> > > some applications in X without any noticeable lag due to faulting in
> > > some pages (that is a bit subjective, I must admit, but I was willing
> > > to show that bigger images make substantial difference).
> > >
> > > I tested uswsusp with compression (LZF) and two image sizes: 120 MB and
> > > (IIRC) about 220 MB on a 256 MB box.  The result of the measurement for
> > > the 120 MB image has always been greater than for the 220 MB image, but
> > > the difference has never been greater than 10%.
> >
> > Ah ok. Are you sure you're getting that sort of throughput with LZF
> > though - if you're not, you might be underestimating the advantage.
>
> Certainly I don't get that kind of speedup for writing.  For reading I do.

Hmm. I would have expected it to be the other way round, since I guess you 
need to do the reading synchronously - or do you read the image, then 
decompress it? (I'm reading and decompressing at the same time, using 
readahead to avoid waiting for pages all the time).

I haven't had the chance to revisit uswsusp yet - I did sysfs support on 
Monday (took ages to figure it out!). Ah... so many things to do, and so 
little time to do them all!

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Rafael J. Wysocki]

Hi,

On Wednesday 12 July 2006 01:00, Nigel Cunningham wrote:
> Hi.
> 
> On Wednesday 12 July 2006 08:34, Rafael J. Wysocki wrote:
> > On Wednesday 12 July 2006 00:01, Nigel Cunningham wrote:
> > > On Wednesday 12 July 2006 07:54, Rafael J. Wysocki wrote:
> > > > On Tuesday 11 July 2006 14:45, Nigel Cunningham wrote:
> > > > > Was that 10% speedup on suspend or resume, or both? With LZF, I see
> > > > > approximately double the speed with both reading and writing:
> > > >
> > > > I was not referring to the speedup of writing and/or reading.
> > > >
> > > > The exercise was to measure the time needed to suspend the system and
> > > > get it back in a responsive state.  I measured the time elapsed between
> > > > triggering the suspend and the moment at which I could switch between
> > > > some applications in X without any noticeable lag due to faulting in
> > > > some pages (that is a bit subjective, I must admit, but I was willing
> > > > to show that bigger images make substantial difference).
> > > >
> > > > I tested uswsusp with compression (LZF) and two image sizes: 120 MB and
> > > > (IIRC) about 220 MB on a 256 MB box.  The result of the measurement for
> > > > the 120 MB image has always been greater than for the 220 MB image, but
> > > > the difference has never been greater than 10%.
> > >
> > > Ah ok. Are you sure you're getting that sort of throughput with LZF
> > > though - if you're not, you might be underestimating the advantage.
> >
> > Certainly I don't get that kind of speedup for writing.  For reading I do.
> 
> Hmm. I would have expected it to be the other way round, since I guess you 
> need to do the reading synchronously - or do you read the image, then 
> decompress it? (I'm reading and decompressing at the same time, using 
> readahead to avoid waiting for pages all the time).

We're doing something like you are, but I think we're using some other option
in LZF, because the resulting image size is 30-40% of the uncompressed one.
That's better for encryption later on, but obviously not for speed.

Greetings,
Rafael

Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

Hi.

On Wednesday 12 July 2006 20:09, Rafael J. Wysocki wrote:
> We're doing something like you are, but I think we're using some other
> option in LZF, because the resulting image size is 30-40% of the
> uncompressed one. That's better for encryption later on, but obviously not
> for speed.

Maybe it's just that the caches compress better? 50% is common, but lower 
values are sometimes seen.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]