Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham <nigel@suspend2.net>]

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

Hi.

On Sunday 19 February 2006 00:26, Pavel Machek wrote:
> Hi!
>
> Thanks for a fresh air in this flamewar...
>
> > I have to completly agree with Sebastian here. 16 months ago I was in
> > the need to have a suspend mode running on my new notebook. Back then
> > Suspend 2 was the only choice, and while it had still problems it was
> > surprisingly well behaving (in contrast to S3 mode and the mainline
> > swsusp). The support of the community was, as said above, very good, and
> > most issues very fixed fast.
>
> Can you test recent swsusp?
>
> > Since it worked good for me, I started to contribute by supplying Fedora
> > patched kernels, helper packages and some documentation. Today on
> > Fedora, it is as easy as installing 4 RPM-packages and adding the
> > "resume2=" parameter to the kernel commandline, and I know that it works
> > this well on several other distributions too.
>
> ...well, thanks for your good work.
>
> > Some more numbers: judging from my access logs and the feedback I get, I
> > suspect at least 2000 Fedora users using Suspend 2 on a regular basis
> > with success. Listening to the IRC channel and reading the forums and
> > wikis, I see a huge bunch of people using Suspend 2 on nearly every
> > distribution. The problems are incredible low, mostly minor things that
> > get fixed nearly instantly.
>
> Well, at least Fedora and SuSE ship swsusp by default. So it is getting
> huge ammount of testing, too.
>
> > Some pros of Suspend 2 from my view:
> > - it is reliable and stable (really!)
> > - it is fast (10-30 seconds on my notebook with 1280 MB ram, depending
> >   on how much caches are saved)
> > - it can save all buffers and caches and the system is instantly
> >   responsible after resume (even Windows cannot do this and is very slow
> >   the first minute after resume)
> > - it works on all major platforms (x86, SMP, x86_64, there were success
> >   reports for PPC, and I believe even ARM works)
> > - and the most important thing, as already said, it is available _today_
>
> swsusp is also available today, and works better than you think. It is
> slightly slower, but has all the other
> features you listed in 2.6.16-rc3.

It is a lot slower because it does all it's I/O synchronously, doesn't 
compress the image and throws away memory until at least half is free.

> > The only con I see is the complexity of the code, but then again, Nigel
>
> ..but thats a big con.

It's fud. Hopefully as I post more suspend2 patches to LKML, people will see 
that Suspend2 is simpler than what you are planning.

> > Again, you said the code is complex, it might be, but still most part of
> > the code is completly seperate from the rest of the kernel, and only
> > touches minor things (and Nigel is still working on that). I believe it
> > would not hurt.
>
> It would hurt at least me, Andrew and Linus... It would make lot
> of suspend2 users very happy...

Pavel, you're very good at making general hand waving statements, but terrible 
at backing them up with facts, specifics or technical arguments. Could you 
please do some more of the later?

> > From a user, and contributor, point of view, I really do not understand
> > why not even trying to push a working implementation into mainline (I
> > know that you cannot just apply the Suspend 2 patches and shipping it,
>
> It is less work to port suspend2's features into userspace than to make
> suspend2 acceptable to mainline. Both will mean big changes, and may
> cause some short-term problems, but it will be less pain than
> maintaining suspend2 forever. Please help with the former...

That's not true. I've taken time to look at what would be involved in making 
suspend2 match the changes you're doing, and I've decided it's just not worth 
the effort.

Let's be clear. uswsusp is not really moving suspend-to-disk to userspace. 
What it is doing is leaving everything but some code for writing the image in 
kernel space, and implementing ioctls to give a userspace program the ability 
to request that other processes be frozen, the snapshot prepared and so on. 
Pages in the snapshot are copied to userspace, possibly compressed or 
encrypted there in future, then fed back to kernel space so it can use the 
swap routines to do the writing. Very little of substance is being done in 
userspace. In short, all it's doing is adding the complexity of always 
requiring a userspace program, an initrd/ramfs, kernel routines to (1) export 
the snapshot to userspace  (2) receive pages to be written, and (3) let 
userspace initiate the real work. It adds the complexity you complain about, 
but with no addition in functionality or usability.

Regards,

Nigel

-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode

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