Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2:hang in atomic copy)

From: Nigel Cunningham
Date: Wed Apr 25 2007 - 04:49:07 EST


On Wed, 2007-04-25 at 07:29 +0000, Pavel Machek wrote:
> Hi!
> > > I absolutely detest all suspend-to-disk crap. Quite frankly, I hate
> > > the whole thing. I think they've _all_ caused problems for the "true"
> > > suspend (suspend-to-ram), and the last thing I want to see is three or
> > > four different suspend-to-disk implementations. So unlike Ingo, I
> > > don't think "let's just integrate them all side-by-side and maintain
> > > them and look who wins" is really a good idea.
> > >
> > > How many different magic ioctl's does the thing introduce? Is it
> > > really just *two* entry-points (and how simple are they,
> > > interface-wise), and nothing else?
> >
> > userspace-driven-suspend is already in the kernel, today. So it's not
> > really "two versions side by side doing the same thing", but more of:
> >
> > A B C + D E F G H
> >
> > where "ABC" is used by the uswsusp code today, and "ABCDEFGH" is used by
> > suspend2. So any "suspend2 merge" would largely be about adding "DEFGH".
> Actually, we have 'D H' in kernel, today. It is called swsusp...
> (Encryption, swapFile support and Graphical progress are missing from
> today's kernel.)

Along with a lot of other things (see my "Reasons to merge Suspend2"
email from earlier in the day).

> > My original mail was about the following thing: i tried the suspend2
> > patch (which just makes "echo disk > /sys/power/state" work as expected,
> > as long as you give the booting up kernel image an idea about where the
> ..and it means that 'echo disk > ...' should work w/o suspend2 patch,
> too. (Just try it). You'll miss compression part, but that provides
> only small speedup.

Please don't spread misinformation to support your case. LZF compression
(which is what all Suspend2 users use AFAIK) generally doubles the speed
of your cycle.


Attachment: signature.asc
Description: This is a digitally signed message part