[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <851fc09e0709210625l6a2d2ed9oeac921fbd5414f84@mail.gmail.com>
Date: Fri, 21 Sep 2007 21:25:13 +0800
From: "huang ying" <huang.ying.caritas@...il.com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: "Andrew Morton" <akpm@...ux-foundation.org>,
"Nigel Cunningham" <ncunningham@...a.org.au>, nigel@...pend2.net,
"Pavel Machek" <pavel@....cz>,
"Huang, Ying" <ying.huang@...el.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"Jeremy Maitin-Shepard" <jbms@....edu>,
linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
"Kexec Mailing List" <kexec@...ts.infradead.org>,
"Len Brown" <lenb@...nel.org>
Subject: Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
On 9/21/07, Rafael J. Wysocki <rjw@...k.pl> wrote:
> Hi Andrew,
>
> On Friday, 21 September 2007 03:41, Andrew Morton wrote:
> > On Fri, 21 Sep 2007 11:19:59 +1000 Nigel Cunningham <ncunningham@...a.org.au> wrote:
> >
> > > Hi.
> > >
> > > On Friday 21 September 2007 11:06:23 Andrew Morton wrote:
> > > > On Fri, 21 Sep 2007 10:24:34 +1000 Nigel Cunningham
> > > <nigel@...el.suspend2.net> wrote:
> > > >
> > > > > Hi Andrew.
> > > > >
> > > > > On Thursday 20 September 2007 20:09:41 Pavel Machek wrote:
> > > > > > Seems like good enough for -mm to me.
> > > > > >
> > > > > > Pavel
> > > > >
> > > > > Andrew, if I recall correctly, you said a while ago that you didn't want
> > > > > another hibernation implementation in the vanilla kernel. If you're going
> > > to
> > > > > consider merging this kexec code, will you also please consider merging
> > > > > TuxOnIce?
> > > > >
> > > >
> > > > The theory is that kexec-based hibernation will mainly use preexisting
> > > > kexec code and will permit us to delete the existing hibernation
> > > > implementation.
> > > >
> > > > That's different from replacing it.
> > >
> > > TuxOnIce doesn't remove the existing implementation either. It can
> > > transparently replace it, but you can enable/disable that at compile time.
> >
> > Right. So we end up with two implementations in-tree. Whereas
> > kexec-based-hibernation leads us to having zero implementations in-tree.
>
> Well, I don't quite agree.
>
> For now, the kexec-based approach is missing the handling of devices, AFAICS.
> Namely, it's quite easy to snapshot memory with the help of kexec, but the
> state of devices gets trashed in the process, so you need some additional code
> saving the state of devices for you, executed before the kexec.
>
> Moreover, on ACPI systems the transition to the S4 sleep state and back to S0
> (working state) is more complicated than a system checkpointing, because we
> are supposed to take the platform firmware into consideration in that case.
> The more I think about this, the more it seems to me that it just can't be done
> on top of kexec in a reasonable fashion. Of course, we could avoid handling
> the ACPI S4, but that would leave some people (including me ;-)) with
> semi-working hardware after the "restore". I don't think that's generally
> acceptable in the long run.
>
> IMHO, for ACPI systems the way to go is to harden suspend to RAM (with s2ram
> in place and the graphics adapters specifications from Intel and AMD released
> we are in a good position to do that) and build the S4 transition mechanism
> on top of that. It can be done easlily by adapting the current hibernation
> code, but not on top of kexec (I'm afraid).
Yes. ACPI is a biggest issue of kexec based hibernation now. I will
try to work on that. At least I can prove whether kexec based
hibernation is possible with ACPI.
> [Besides, the current hibernation userland interface is used by default by
> openSUSE and it's also used by quite some Debian users, so we can't drop
> it overnight and it can't be implemented in a compatible way on top of the
> kexec-based solution.]
Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists