Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

Martin Steigerwald
2007-05-26T17:38:18Z

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

Am Mittwoch 25 April 2007 schrieb Pavel Machek:
> Hi!
>
> > This is why there's a lot to be said for
> >
> > echo mem > /sys/power/state
> >
> > and being able to follow the path through _one_ object (the kernel)
> > over trying to figure out the interaction between many different
> > parts with different versions.
>
> The 'promise' is 'if you can get echo disk > /sys/power/state working,
> uswsusp will work. too'. IOW it should be ok to debug the in-kernel
> parts, only.

Hello Nigel, Pavel, Rafael and everyone else who is involved,

I would like to ask what come out of the suspend2 merge discussion. Nigel
just told that suspend2 likely won't be merged anytime soon and thats its
business as usual:

---------------------------------------------------------------------
It's pretty much business as usual. Linus doesn't want another
implementation merged, and he wants the three of us (Pavel, Rafael and
myself) to agree on a way forward. He also believes that we're
approaching things from the wrong direction at the moment. Funnily
enough, this is the one area on which we do all agree.
---------------------------------------------------------------------
http://lists.suspend2.net/lurker/message/20070510.021641.fe306add.en.html

Has there been any further discussion and preferably agreement on the way
to go forward?

Although you Linus, as I read from different mails only use suspend to
RAM, there are many users out there who use suspend to disk daily.

I used in kernel software suspend initially and it worked quite nice with
starting from 2.6.10 or 2.6.11 where suspend2 didn't work for me before
2.6.14 with the hibernate script. But from then on suspend2 worked better
than in kernel software suspend for me and colleagues on:

- ThinkPad T23
- ThinkPad T42
- Possibly some other ThinkPads
- as well various Dell workstations we have at work

It was faster and more reliable, yielding uptimes up to 40 days on my
workstation recently (with 2.6.17.7 still). And even that uptime was only
ended by booting a newly build kernel (2.6.21 with sws 2.2.9.13). For me
in the role of a user actually this is a really satisfying solution!

I tried userspace software suspend from time to time but then just was fed
up with it, cause I could not get it to work within any sensible amount
of time - even with some bog standard Debian kernel, I think it was some
2.6.18 one. Maybe I am dumb, but so be it, it should not be that
complicated to get it to work. Recently I didn't even bother to try
anymore. Well and I read in the suspend2 merge discussion that even in
kernel suspend does not work reliably anymore.

As long I cannot be convinced that the vanilla kernel contains a suspend
to disk solution that works as good as suspend2 I will patch suspend2
into all of the desktop kernels I build.

Thats quite bad IMHO for exactly the same reason than having drivers
maintained out of the kernel. For the same reason I think swap prefetch
should go in as soon as possible. It will never have the adoption and
care taking of an in-kernel-tree solution.

I am convinced that a working suspend to RAM just is not enough - well it
wasn't working correctly last time I checked. But I even don't bother
about suspend to RAM anymore. I can wait those additional seconds for
suspend to disk and it allows me to drive my laptops without batteries
most of the time and have workstations switched off completely so that
they do not consume standby power.

So please, pretty please consider working together on a reliable, fast,
stable, easy to use and configurable in-kernel-tree snapshot solution!
Actually I as a user I couldn't care less about the implementation
details, but as someone who is interested in kernel technologies I like
it to be a clean and well designed solution, too. ;-)

Maybe when the Linux Foundation organizes a meeting for Nigel, Pavel,
Rafael and other kernel developers interested in creating such a solution
it will help. To me it seems such a concentrated meeting in a good
atmosphere could be more effective than endless mailing list discussions
not leading to a clear result. When its not easy for the involved people
to work together maybe a casual bystander who understands enough of
kernel details should moderate the meeting and help finding an agreement.

It would just be such a pity to miss the chance to have a nicely working
snapshot solution in the Linux kernel, that may even be interesting for
virtualization (you could store a backup of a machine state permanently
or even more of them - if not already available through other
technologies like well suspend2 with filewriter for example).

Regards,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]