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: 3770 bytes --]

Hi.

On Monday 20 February 2006 07:29, Pavel Machek wrote:
> Hi!
>
> > > 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.
>
> uswsusp does compress image (20% speedup, in recent CVS) and do
> asynchronous I/O.

Only 20? You must be doing something horribly wrong. Asynchronous I/O shoudl 
get the speed from whatever you're getting without it to the maximum the 
drive can handle. LZF should double the speed again on a CPU that's fast 
enough that the bottleneck is the disk.

> > > > 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.
>
> For what I'm planning, all the neccessary patches are already in -mm
> tree. And they are *really* simple. If you can get suspend2 to 1000
> lines of code (like Rafael did with uswsusp), we can have something to
> talk about.

Turn it round the right way. If you can get the functionality of Suspend2 
using userspace only, then we have something to talk about.

> > > > 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
>
> Maybe very little of substance is being done in userspace, but all the
> uglyness can stay there. I no longer need LZF in kernel, special
> netlink API for progress bar (progress bar naturally lives in
> userland), no plugin infrastructure needed, etc.

And you do need?...

> If you can do suspend2 without putting stuff listed above into kernel,
> and in acceptable ammount of code... we can see. But you should really
> put suspend2 code into userspace, and be done with that. Feel free to
> spam l-k a bit more, but using existing infrastructure in -mm is right
> way to go, and it is easier, too.

It is only easier because you're not comparing apples with apples. I have no 
desire to spam LKML with this pointless discussion, so I'm just going to get 
on with submitting patches for review.

Rgards,

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 --]