Hi!
> > > 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
20% is speedup for compression alone, over whole suspend
process. Device suspend/resume takes lot of time in recent kernels.
> > > > > 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.
Only feature I can't do is "save whole pagecache"... and 14000 lines
of code for _that_ is a bit too much. I could probably patch my kernel
to dump pagecache to userspace, but I do not think it is 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?...
I do not need anything more than what is already in -mm tree.
> > 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.
So please take my comments from "suspend2 review" mail into account.
Pavel
--
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
