[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1177490928.3857.27.camel@nigel.suspend2.net>
Date: Wed, 25 Apr 2007 18:48:48 +1000
From: Nigel Cunningham <nigel@...el.suspend2.net>
To: Pavel Machek <pavel@....cz>
Cc: Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Christian Hesse <mail@...thworm.de>,
Nick Piggin <npiggin@...e.de>, Mike Galbraith <efault@....de>,
linux-kernel@...r.kernel.org, Con Kolivas <kernel@...ivas.org>,
suspend2-devel@...ts.suspend2.net,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2:
hang in atomic copy)
Hi.
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.
Nigel
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists