Messages in this thread | | | Date | Sat, 8 Jul 2006 13:22:45 +0200 | From | Pavel Machek <> | Subject | Re: uswsusp history lesson [was Re: [Suspend2-devel] Re: swsusp / suspend2 reliability] |
| |
Hi!
> > I really looked at suspend2 hard, year or so ago, when I was pretty > > tired of the flamewars. At that point I decided it is way too big to > > be acceptable to mainline, and got that crazy idea about uswsusp, that > > surprisingly worked out at the end. > > > > uswsusp makes suspend2 obsolete, and suspend2 now looks > > misdesigned. It puts too much stuff into the kernel, you know that > > already. > > No, I don't. From my point of view, uswsusp is misdesigned, but suspend2 > isn't. Suspend2 keeps the stuff that ought to be done by the kernel in the > kernel. It doesn't shift data out to userspace, only to copy it straight back > to the kernel for I/O. It will keep working even if userspace crashes and > burns.
Copying back and forth is not a problem (3GB/sec RAM bandwidth vs. 50MB/sec disk bandwidth), and at least we do not have to add LZF to kernel.
> > From your point of view, uswsusp is misdesigned, too. It is too damn > > hard to install. There's no way it could survive as a standalone patch > > -- the way suspend2 survives. Fortunately, from distro point of view, > > being hard to install does not matter that much. Distros already have > > their own initrds, etc. And in the long term, distros matter, and I'm > > quite confident I can make 90% distributions ship uswsusp + its > > userland; cleaner kernel code matters, too, and maybe you'll agree > > that if you only look at the kernel parts, uswsusp looks nicer. > > It looks simple, I agree. But that's only because it's doing the minimum > required.
Yes, and that's exactly how kernel design should work.
> > Now... switching to uswsusp kernel parts will make it slightly harder > > to install in the short term (messing with initrd). OTOH there's at > > least _chance_ to get to the point where suspend "just works" in > > Linux, in the long term... > > > > (Of course, you can just ignore this and keep maintaining out-of-tree > > suspend2. We'll also get to the point where it "just works"... it will > > just take a little longer.) > > With your current design, I don't see how you're ever going to get to the > level of functionality that Suspend2 has. I'm of course thinking of a full > image of memory (although Rafael's patch a while back looked hopeful there) > and support for other-than-just-one-swap-partition.
Rafael's code was nice hack, unfortunately noone was able to review it, so it is on hold. (You'll have similar problems, BTW; that LRU issues are really "interesting").
other-than-just-one-swap-partition is a weekend task for someone motivated. (And not even dangerous to your data, given that we can do checksums.) [Any volunteers? Given ammount of trafic in my inbox, suspend is still interesting topic.] 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/
| |