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

[Pavel Machek <pavel@suse.cz>]

Hi!

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

No, if your main loop is already in userspace, you do not need to add
any more code. And you'd save way more than 1000 lines:

* encryption/compression can be removed

* but that means that writer plugins/filters can be removed

* if you do compress/encrypt in userspace, you can remove that ugly
netlink thingie, and just display progress in userspace, too

...and then, image writing can be moved to userspace...

* swapfile support

* partition support

* plus their plugin infrastructure.

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

Aha, that's probably better done with Xen, anyway :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/