On Saturday, 14 July 2007 12:55, Huang, Ying wrote:
> On Sat, 2007-07-14 at 11:59 +0200, Rafael J. Wysocki wrote:
> > > Hibernating process:
> > >
> > > 1. Normal kernel running
> > > 2. Hibernating is triggered, sys_kexec_load is used to load
> > > hibernating kernel and initramfs into memory. Then
> > > sys_reboot(LINUX_REBOOT_CMD_KSPAWN) is invoked.
> > > 3. In sys_reboot, kexec_jump is called to save device/CPU state,
> > > then relocate_kernel is called. kexec_jump and relocate_kernel
> > > reside in individual page in 16M~512M.
> >
> > OK
> > What's going to happen to devices at this point?
> >
>
> The devices should be quiesced and the state of devices should be saved
> in kexec_jump, before relocate_kernel is called. This needs the
> implementation of device hibernating as you mentioned before.
Hmm, at which point devices are normally shut down when kexec is used?
> > > 4. In relocate_kernel, 0~16M is backupped firstly, then the
> > > hibernating kernel and initramfs is copied to 0~16M, after that,
> > > the hibernating kernel is booted.
> > > 5. In hibernating kernel, the memory of normal kernel (it is in
> > > 16M~512M) is saved into a hibernation image through /dev/mem
> > > and ELF header.
> >
> > I don't think it can be _that_ simple:
> > (a) what about processes' memory
> > (b) what about areas that shouldn't be saved?
>
> The mem_map (struct page[]) of every zone of hibernated kernel is
> checked. Necessary pages are saved, like memory snapshot of software
> suspend, but in user space.
Well, it's not enough to check that, sorry. That's why we have
register_nosave_region().
> > > Resume process:
> > >
> > > 1. Resuming kernel is booted as a normal kernel, but the memory is
> > > restricted to 0~16M.
> > > 2. Checking whether there is a effective hibernation image. If
> > > there isn't, the memory of 16M~512M is hot added, and the normal
> > > boot up process continues; If there is, a resuming process is
> > > triggered.
> > > 3. sys_kexec_load is used to restore the memory state of hibernated
> > > kernel. The sys_kexec_load works in crashdump way, that is, the
> > > hibernation image is copied to destination location in 16M~512M
> > > in sys_kexec_load instead of relocate_kernel. There is no half
> > > of memory size restriction.
> > > 4. sys_reboot is called to trigger jumping back, which will jump back
> > > to kexec_jump of hibernated kernel.
> > > 5. In kexec_jump of hibernated kernel, the memory of 0~16M is copied
> > > back from the backup area in 16M~512M. The memory state of
> > > hibernated kernel is restored totally. The CPU and device state
> > > can be restored after that.
> >
> > Well, I don't know why this needs to be that complicated. We already have
> > code in the mainline that's able to load a large hibernation image into memory
> > and jump to the kernel being restored. And it has _no_ 50% of RAM limitation,
> > this is the _saving_ part of the current code that this limitation comes from.
>
> There is much similarity between sys_kexec_load and software resuming.
> If resuming can be done by sys_kexec_load, then we need not two similar
> functionality in kernel.
Oh, I see, but your proposed solution seems to be more complicated than that.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
