Re: [Suspend2][ 0/9] Extents support.

[Nigel Cunningham <nigel@suspend2.net>]

Hi.

On Thursday 29 June 2006 07:11, Pavel Machek wrote:
> Hi!
>
> > > > Now I haven't followed the suspend2 vs swsusp debate very closely,
> > > > but it seems to me that your biggest problem with getting this merged
> > > > is getting consensus on where exactly this is going. Nobody wants two
> > > > different suspend modules in the kernel. So there are two options -
> > > > suspend2 is deemed the way to go, and it gets merged and replaces
> > > > swsusp. Or the other way around - people like swsusp more, and you
> > > > are doomed to maintain suspend2 outside the tree.
> > >
> > > Actually, there's a third option that is looking like the way forward,
> > > doing all of this from userspace and having no suspend-to-disk in the
> > > kernel tree at all.
> > >
> > > Pavel and others have a working implementation and are slowly moving
> > > toward adding all of the "bright and shiny" features that is in
> > > suspend2 to it (encryption, progress screens, abort by pressing a key,
> > > etc.) so that there is no loss of functionality.
> > >
> > > So I don't really see the future of suspend2 because of this...
> >
> > But what Rafael and Pavel are doing is really only moving the highest
> > level of controlling logic to userspace (ok, and maybe compression and
> > encryption too). Everything important (freezing other processes, atomic
> > copy and the guts of the I/O) is still done by the kernel.
>
> Can you do the same and move compression/encryption to userspace, too?
>
> And actually that "highest level" covers >50% of suspend2 code. That
> would be around 7K lines of code removed from kernel if you did the
> same, and suspend2 patch would be half the size...

That's not true. The compression and encryption support add ~1000 lines, as 
you pointed out the other day. If I moved compression and encryption support 
to userspace, I'd remove 1000 lines and:

- add more code for getting the pages copied to and from userspace
- require the user to get and build $LIBRARIES for doing the compression
- require the user to get and build $HELPER for doing the interface to 
Suspend2
- fail to leverage the perfectly good cryptoapi routines that are already 
there
- slow the whole process down because I'd now have a copy to userspace for 
every page being compressed/encrypted and a copy from userspace for every 
output page.
- make life more complicated for distro maintainers and users because they'd 
have another set of dependencies to worry about and mess with.

I'm not saying it's impossible. I'm just saying it would make suspending more 
complicated, at least potentially slower and more of a pain for everyone. On 
top of that, imagine if someone comes along and writes their own wizz-bang 
compression module, then complains (without telling you they did it) that 
Suspend2 trashed their hard disk when the bug is actually in their code. It's 
another way in which your kernel can be tainted :)

> > And there _is_ loss of functionality - uswsusp still doesn't support
> > writing a full image of memory, writing to multiple swap devices
> > (partitions or files), or writing to ordinary files. They're getting the
> > low hanging fruit, but when
>
> That's userspace problem. Of course we are after low-hanging fruit,
> first, but uswsusp design (AND CURRENT KERNEL PARTS) allow you to get
> all the fruit with the right userspace.
>
> > it comes to these parts of the problem, they're going to require either
> > smoke and very good mirrors (eg the swap prefetching trick), or simply
> > refuse to implement them.
> >
> :-) I like the mirrors idea. Anyway Rafael *did* get code for saving
>
> whole memory at one point, but it looked quite dangerous to me. It was
> ~300 lines. I'm sure it can be resurrected.
>
> > If we take the problem one step further, and begin to think about
> > checkpointing, they're in even bigger trouble. I'll freely admit that I'd
> > have to redesign the way I store data so that random parts of the image
> > could be replaced, have hooks in mm to be able to learn what pages need
> > have changed and would also need filesystem support to handle that part
> > of the problem, but I'd at least be working in the right domain.
>
> Could you explain? I do not get the checkpointing remark.

Sure. Suspending to disk is a pretty similar problem to checkpointing, except 
that you want to continue running afterwards, keep the image and modify it 
from time to time based on the changes in memory (having a checkpointing 
filesystem too, of course). My point is that modifying uswsusp to do 
checkpointing would be far harder precisely because you've pushed the highest 
level logic to userspace. It would be far more complicated, if not impossible 
for you to make the adjustments to do checkpointing.

Regards,

Nigel

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

Attachment: pgpD8v9qR5sCI.pgp
Description: PGP signature