From: Pavel Machek <pavel@...>
Subject: Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Date: Sep 20, 6:09 am 2007
Hi!
> This patch implements the functionality of jumping between the kexeced
> kernel and the original kernel.
>
> A new reboot command named LINUX_REBOOT_CMD_KJUMP is defined to
> trigger the jumping to (executing) the new kernel and jumping back to
> the original kernel.
>
> To support jumping between two kernels, before jumping to (executing)
> the new kernel and jumping back to the original kernel, the devices
> are put into quiescent state (to be fully implemented), and the state
> of devices and CPU is saved. After jumping back from kexeced kernel
> and jumping to the new kernel, the state of devices and CPU are
> restored accordingly. The devices/CPU state save/restore code of
> software suspend is called to implement corresponding function.
>
> To support jumping without preserving memory. One shadow backup page
> is allocated for each page used by new (kexeced) kernel. When do
> kexec_load, the image of new kernel is loaded into shadow pages, and
> before executing, the original pages and the shadow pages are swapped,
> so the contents of original pages are backuped. Before jumping to the
> new (kexeced) kernel and after jumping back to the original kernel,
> the original pages and the shadow pages are swapped too.
>
> A jump back protocol is defined and documented.
> Signed-off-by: Huang Ying
Seems like good enough for -mm to me.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
From: Nigel Cunningham <nigel@...>
Subject: Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Date: Sep 20, 8:24 pm 2007
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?
Regards,
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
-
From: Pavel Machek <pavel@...>
Subject: Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Date: Sep 21, 5:49 am 2007
Hi!
> > Seems like good enough for -mm to me.
(For the record, I do not think this is going to be
hibernation-replacement any time soon. But it is functionality useful
for other stuff -- dump memory and continue -- and yes it may be able
to do hibernation in the long term.
It really comes from the other side of reliability:
* swsusp is "if your kernel is perfectly healthy, it will work"
while this, coming from kdump is
* "if your kernel is not completely trashed, it should work"
...which is why can't use swsusp to do dump memory and continue -- you
want to do dumps on "slightly broken" systems. And yes, as a
sideeffect it may be able to do hibernation... why not, lets see how
it works out).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
From: Andrew Morton <akpm@...>
Subject: Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Date: Sep 20, 9:06 pm 2007
On Fri, 21 Sep 2007 10:24:34 +1000 Nigel Cunningham 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.
-
From: Nigel Cunningham <ncunningham@...>
Subject: Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Date: Sep 20, 9:19 pm 2007
Hi.
On Friday 21 September 2007 11:06:23 Andrew Morton wrote:
> On Fri, 21 Sep 2007 10:24:34 +1000 Nigel Cunningham
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.
Regards,
Nigel
--
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.
-
From: Andrew Morton <akpm@...>
Subject: Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Date: Sep 20, 9:41 pm 2007
On Fri, 21 Sep 2007 11:19:59 +1000 Nigel Cunningham wrote:
> Hi.
>
> On Friday 21 September 2007 11:06:23 Andrew Morton wrote:
> > On Fri, 21 Sep 2007 10:24:34 +1000 Nigel Cunningham
> 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.
See, it's different.
-
From: Rafael J. Wysocki <rjw@...>
Subject: Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Date: Sep 21, 7:56 am 2007
Hi Andrew,
On Friday, 21 September 2007 03:41, Andrew Morton wrote:
> On Fri, 21 Sep 2007 11:19:59 +1000 Nigel Cunningham wrote:
>
> > Hi.
> >
> > On Friday 21 September 2007 11:06:23 Andrew Morton wrote:
> > > On Fri, 21 Sep 2007 10:24:34 +1000 Nigel Cunningham
> > 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).
[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.]
-
From: huang ying <huang.ying.caritas@...>
Subject: Re: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump
Date: Sep 21, 9:25 am 2007
On 9/21/07, Rafael J. Wysocki wrote:
> Hi Andrew,
>
> On Friday, 21 September 2007 03:41, Andrew Morton wrote:
> > On Fri, 21 Sep 2007 11:19:59 +1000 Nigel Cunningham wrote:
> >
> > > Hi.
> > >
> > > On Friday 21 September 2007 11:06:23 Andrew Morton wrote:
> > > > On Fri, 21 Sep 2007 10:24:34 +1000 Nigel Cunningham
> > > 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
-
What does he mean??
"At least I can prove whether kexec based hibernation is possible with ACPI."
What does he mean by that? As far as I know, TuxOnIce works with ACPI too >.<
Yes, but TuxOnFrozenWater is
Yes, but TuxOnFrozenWater is not kexec based...
ACPI too complex
ACPI is a too complex specification. It is over 600 pages long.
http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface
Today's hardware is much to
Today's hardware is much to complex. It was engineered by "proprietary" hardware engineers who are not really capable of writing good software on a proprietary operating system. What did you expect?
It's like the operating systems before UNIX. UNIX simplified everything (ok, except BSD sockets, etc. - but Plan 9 really does).
So what? It's reality, and
So what? It's reality, and we can't just say "It's crap, let's ignore it"
Yes, you're right
Yes, you're right. It's reality.
So I will just keep on dreaming about a computer that don't have or need ACPI, because it is so energy efficient.
Solid-state disk drives. No fans. 1w graphics card. 1w CPU. Yes, that would be lovely...
Agreed
(OP here)
I completely agree, we're all looking forward to that happening (and ACPI going the same way as MCA), but it'll be a long way before we can even consider ignoring ACPI in the kernel, so it's a pretty useless debate (in kernel context, that is).
OLPC ?
This is more-or-less what OLPC did, right ? And they thrown away ACPI because it was too complex and ultimately unneeded... Except Geode combines CPU and GPU in one low-power package...
ACPI does a good bit more
ACPI does a good bit more than just power management. At this year's OLS there was a paper titled "ACPI in Linux – Myths vs. Reality," which covers a lot of what ACPI does, including defining the E820 memory map, IRQ routing interfaces, and multiprocessor functionality (HT doesn't work without ACPI, for instance). ACPI didn't just replace APM, it also replaced MPS (the old Multiprocessor Specification) and the old PCI IRQ routing specification. That's part of why it's so complex.
Cannot anyone see this is more functional.
The ability to swap between running kernels is far more powerful than the hibernation systems. If it happens to take out hibernation as well so be it.
Adding the means to swap between active kernel in memory is only stage one. Stage 2 to transfer the running applications off one kernel without disruption. No more reboots to upgrade kernel. In theory it could be 100 percent invisible that you have even changed a kernel.
Fixing the niggling stability issues third party provide video drivers for X11 is the final step to a zero reboot OS. Maybe for this extend containers down into kernel space. Hmm kernel panic happened in this stack of drivers clean up an repair by restarting everything in that container including the related drivers.
This is not about hibernation its about zero downtime. Just part of zero downtime required hibernation like stuff.