Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
huang ying wrote: On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: huang ying wrote: On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patches (or download the source tar ball directly) and compile. 3. Download and compile the krestore tool. 4. Prepare 2 root partition used by kernel A and kernel B/C, referred as /dev/hda, /dev/hdb in following text. This is not strictly necessary, I use this scheme for testing during development. 5. Boot kernel compiled for normal usage (kernal A). 6. Load kernel compiled for hibernating/restore usage (kernel B) with kexec, the same kernel as that of 5 can be used if CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. The --elf64-core-headers should be specified in command line of kexec, because only the 64bit ELF is supported by krestore tool. For example, the shell command line can be as follow: kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --append="root=/dev/hdb single" 7. Jump to the hibernating kernel (kernel B) with following shell command line: kexec -j 8. In the hibernating kernel (kernel B), the memory image of hibernated kernel (kernel A) can be saved as follow: cp /proc/vmcore . cp /sys/kernel/kexec_jump_back_entry . Here we save also kernel B's pages. No, the kernel B's pages will not be saved. Because when we build the elfcore (/proc/vmcore) header, we exclude memory area used by kernel B. The details can be found in kexec-tools patches. Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in order not to allocate pages found also in A's space? Or does does the --mem-min and --mem-max do that also? That is what "memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED]" for. The contents of e820 memmap will be overrided when these kernel parameters are specified. Best Regards, Huang Ying Yes, you just didn't specify exactmap for kernel B in your instructions, but only for C. But it is also required for kernel B then? Thanks, Mika - 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/
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
huang ying wrote: On 9/21/07, Mika Penttilä <[EMAIL PROTECTED]> wrote: Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patches (or download the source tar ball directly) and compile. 3. Download and compile the krestore tool. 4. Prepare 2 root partition used by kernel A and kernel B/C, referred as /dev/hda, /dev/hdb in following text. This is not strictly necessary, I use this scheme for testing during development. 5. Boot kernel compiled for normal usage (kernal A). 6. Load kernel compiled for hibernating/restore usage (kernel B) with kexec, the same kernel as that of 5 can be used if CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. The --elf64-core-headers should be specified in command line of kexec, because only the 64bit ELF is supported by krestore tool. For example, the shell command line can be as follow: kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --append="root=/dev/hdb single" 7. Jump to the hibernating kernel (kernel B) with following shell command line: kexec -j 8. In the hibernating kernel (kernel B), the memory image of hibernated kernel (kernel A) can be saved as follow: cp /proc/vmcore . cp /sys/kernel/kexec_jump_back_entry . Here we save also kernel B's pages. No, the kernel B's pages will not be saved. Because when we build the elfcore (/proc/vmcore) header, we exclude memory area used by kernel B. The details can be found in kexec-tools patches. Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in order not to allocate pages found also in A's space? Or does does the --mem-min and --mem-max do that also? Thanks, Mika - 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/
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patches (or download the source tar ball directly) and compile. 3. Download and compile the krestore tool. 4. Prepare 2 root partition used by kernel A and kernel B/C, referred as /dev/hda, /dev/hdb in following text. This is not strictly necessary, I use this scheme for testing during development. 5. Boot kernel compiled for normal usage (kernal A). 6. Load kernel compiled for hibernating/restore usage (kernel B) with kexec, the same kernel as that of 5 can be used if CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. The --elf64-core-headers should be specified in command line of kexec, because only the 64bit ELF is supported by krestore tool. For example, the shell command line can be as follow: kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --append="root=/dev/hdb single" 7. Jump to the hibernating kernel (kernel B) with following shell command line: kexec -j 8. In the hibernating kernel (kernel B), the memory image of hibernated kernel (kernel A) can be saved as follow: cp /proc/vmcore . cp /sys/kernel/kexec_jump_back_entry . Here we save also kernel B's pages. 9. Shutdown or reboot in hibernating kernel (kernel B). 10. Boot kernel (kernel C) compiled for hibernating/restore usage on the root file system /dev/hdb in memory range of kernel B. For example, the following kernel command line parameters can be used: root=/dev/hdb single memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED] 0-640K from kernel A overrides 0-640K of kernel C at restore time. 11. In restore kernel (kernel C), the memory image of kernel A can be restored as follow: cp kexec_jump_back_entry /sys/kernel/kexec_jump_back_entry krestore vmcore This steps replaces kernel C's pages with kernel B's (at least 15m-16m), saved at step 8, so these kernels should be equal? Or they must be physically located in non-overlapping regions such that C is in B's memory range but non-overlapping. The proposed setup doesn't guaratee this afaics. 12. Jump back to hibernated kernel (kernel A) kexec -b Best Regards, Huang Ying ___ linux-pm mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/linux-pm --Mika - 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/
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
On Fri, 2007-09-21 at 10:43 +0200, Stefan Rompf wrote: > Am Donnerstag, 20. September 2007 07:34 schrieb Huang, Ying: > > > The hibernation procedure with the patch set is as follow: > > > > 1. Boot a kernel A > > > > 2. Work under kernel A > > > > 3. Kexec another kernel B (crash dump enabled) in kernel A. > > From a short glance over current Linus' arch/i386/kernel/machine_kexec.c, > memory for the crash dump kernel B still needs to be reserved statically when > booting A. > > This is one of the biggest issues with kexec based hibernation. For the > typical notebook user, it is totally unacceptable to reserve 16 megabytes of > memory just to be able to suspend to disk. And given the fact that current > distribution kernels are quite modular and require early module loading, even > more memory might be needed. > > IMHO, a plan how to fix this must exist or the concept of kexec based > hibernation is a waste of time. This issue has been resolved. The implementation method details in another mail with title as follow: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump Best Regards, Huang Ying - 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/
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
Am Donnerstag, 20. September 2007 07:34 schrieb Huang, Ying: > The hibernation procedure with the patch set is as follow: > > 1. Boot a kernel A > > 2. Work under kernel A > > 3. Kexec another kernel B (crash dump enabled) in kernel A. >From a short glance over current Linus' arch/i386/kernel/machine_kexec.c, memory for the crash dump kernel B still needs to be reserved statically when booting A. This is one of the biggest issues with kexec based hibernation. For the typical notebook user, it is totally unacceptable to reserve 16 megabytes of memory just to be able to suspend to disk. And given the fact that current distribution kernels are quite modular and require early module loading, even more memory might be needed. IMHO, a plan how to fix this must exist or the concept of kexec based hibernation is a waste of time. Stefan - 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/
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
Am Donnerstag, 20. September 2007 07:34 schrieb Huang, Ying: The hibernation procedure with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. From a short glance over current Linus' arch/i386/kernel/machine_kexec.c, memory for the crash dump kernel B still needs to be reserved statically when booting A. This is one of the biggest issues with kexec based hibernation. For the typical notebook user, it is totally unacceptable to reserve 16 megabytes of memory just to be able to suspend to disk. And given the fact that current distribution kernels are quite modular and require early module loading, even more memory might be needed. IMHO, a plan how to fix this must exist or the concept of kexec based hibernation is a waste of time. Stefan - 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/
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
On Fri, 2007-09-21 at 10:43 +0200, Stefan Rompf wrote: Am Donnerstag, 20. September 2007 07:34 schrieb Huang, Ying: The hibernation procedure with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. From a short glance over current Linus' arch/i386/kernel/machine_kexec.c, memory for the crash dump kernel B still needs to be reserved statically when booting A. This is one of the biggest issues with kexec based hibernation. For the typical notebook user, it is totally unacceptable to reserve 16 megabytes of memory just to be able to suspend to disk. And given the fact that current distribution kernels are quite modular and require early module loading, even more memory might be needed. IMHO, a plan how to fix this must exist or the concept of kexec based hibernation is a waste of time. This issue has been resolved. The implementation method details in another mail with title as follow: [RFC][PATCH 1/2 -mm] kexec based hibernation -v3: kexec jump Best Regards, Huang Ying - 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/
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patches (or download the source tar ball directly) and compile. 3. Download and compile the krestore tool. 4. Prepare 2 root partition used by kernel A and kernel B/C, referred as /dev/hda, /dev/hdb in following text. This is not strictly necessary, I use this scheme for testing during development. 5. Boot kernel compiled for normal usage (kernal A). 6. Load kernel compiled for hibernating/restore usage (kernel B) with kexec, the same kernel as that of 5 can be used if CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. The --elf64-core-headers should be specified in command line of kexec, because only the 64bit ELF is supported by krestore tool. For example, the shell command line can be as follow: kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --append=root=/dev/hdb single 7. Jump to the hibernating kernel (kernel B) with following shell command line: kexec -j 8. In the hibernating kernel (kernel B), the memory image of hibernated kernel (kernel A) can be saved as follow: cp /proc/vmcore . cp /sys/kernel/kexec_jump_back_entry . Here we save also kernel B's pages. 9. Shutdown or reboot in hibernating kernel (kernel B). 10. Boot kernel (kernel C) compiled for hibernating/restore usage on the root file system /dev/hdb in memory range of kernel B. For example, the following kernel command line parameters can be used: root=/dev/hdb single memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED] 0-640K from kernel A overrides 0-640K of kernel C at restore time. 11. In restore kernel (kernel C), the memory image of kernel A can be restored as follow: cp kexec_jump_back_entry /sys/kernel/kexec_jump_back_entry krestore vmcore This steps replaces kernel C's pages with kernel B's (at least 15m-16m), saved at step 8, so these kernels should be equal? Or they must be physically located in non-overlapping regions such that C is in B's memory range but non-overlapping. The proposed setup doesn't guaratee this afaics. 12. Jump back to hibernated kernel (kernel A) kexec -b Best Regards, Huang Ying ___ linux-pm mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/linux-pm --Mika - 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/
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
huang ying wrote: On 9/21/07, Mika Penttilä [EMAIL PROTECTED] wrote: Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patches (or download the source tar ball directly) and compile. 3. Download and compile the krestore tool. 4. Prepare 2 root partition used by kernel A and kernel B/C, referred as /dev/hda, /dev/hdb in following text. This is not strictly necessary, I use this scheme for testing during development. 5. Boot kernel compiled for normal usage (kernal A). 6. Load kernel compiled for hibernating/restore usage (kernel B) with kexec, the same kernel as that of 5 can be used if CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. The --elf64-core-headers should be specified in command line of kexec, because only the 64bit ELF is supported by krestore tool. For example, the shell command line can be as follow: kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --append=root=/dev/hdb single 7. Jump to the hibernating kernel (kernel B) with following shell command line: kexec -j 8. In the hibernating kernel (kernel B), the memory image of hibernated kernel (kernel A) can be saved as follow: cp /proc/vmcore . cp /sys/kernel/kexec_jump_back_entry . Here we save also kernel B's pages. No, the kernel B's pages will not be saved. Because when we build the elfcore (/proc/vmcore) header, we exclude memory area used by kernel B. The details can be found in kexec-tools patches. Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in order not to allocate pages found also in A's space? Or does does the --mem-min and --mem-max do that also? Thanks, Mika - 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/
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
huang ying wrote: On 9/21/07, Mika Penttilä [EMAIL PROTECTED] wrote: huang ying wrote: On 9/21/07, Mika Penttilä [EMAIL PROTECTED] wrote: Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patches (or download the source tar ball directly) and compile. 3. Download and compile the krestore tool. 4. Prepare 2 root partition used by kernel A and kernel B/C, referred as /dev/hda, /dev/hdb in following text. This is not strictly necessary, I use this scheme for testing during development. 5. Boot kernel compiled for normal usage (kernal A). 6. Load kernel compiled for hibernating/restore usage (kernel B) with kexec, the same kernel as that of 5 can be used if CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. The --elf64-core-headers should be specified in command line of kexec, because only the 64bit ELF is supported by krestore tool. For example, the shell command line can be as follow: kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --append=root=/dev/hdb single 7. Jump to the hibernating kernel (kernel B) with following shell command line: kexec -j 8. In the hibernating kernel (kernel B), the memory image of hibernated kernel (kernel A) can be saved as follow: cp /proc/vmcore . cp /sys/kernel/kexec_jump_back_entry . Here we save also kernel B's pages. No, the kernel B's pages will not be saved. Because when we build the elfcore (/proc/vmcore) header, we exclude memory area used by kernel B. The details can be found in kexec-tools patches. Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in order not to allocate pages found also in A's space? Or does does the --mem-min and --mem-max do that also? That is what memmap=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED] for. The contents of e820 memmap will be overrided when these kernel parameters are specified. Best Regards, Huang Ying Yes, you just didn't specify exactmap for kernel B in your instructions, but only for C. But it is also required for kernel B then? Thanks, Mika - 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/
[RFC][PATCH 0/2 -mm] kexec based hibernation -v3
Kexec base hibernation has some potential advantages over uswsusp and TuxOnIce (suspend2). Some most obvious advantages are: 1. The hibernation image size can exceed half of memory size easily. 2. The hibernation image can be written to and read from almost anywhere, such as USB disk, NFS. 3. It is possible to eliminate freezer from kexec based hibernation implementation. 4. Based on kexec/kdump implementation, the kernel code needed is less. This patch set implements the kexec based hibernation. The kernel functionality added are as follow: 1. Jumping between the kexeced kernel and the original kernel. This is used by hibernation to save/load necessary state in original kernel and jumping back to original kernel after restore the memory of original kernel. 2. Add writing support to /dev/oldmem. This is used by hibernation to restore the memory of original kernel. The hibernation procedure with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. 4. Save the memory image of kernel A through crash dump (such as "cp /proc/vmcore ~"). Save the "jump back entry". 5. Shutdown or reboot The restore process with the patch set is as follow: 1. Boot a kernel C (crash dump enabled), the memory area used by kernel C must be a subset of memory area used by kernel B. 2. Restore the memory image of kernel A through /dev/oldmem. Restore the "jump back entry". 3. Jump from kernel C back to kernel A 4. Continue work under kernel A The following user-space tools are needed to implement hibernation and restore. 1. kexec-tools needs to be patched to support kexec jump. The patches and the precompiled kexec can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_20070920/kexec-tools/kexec-tools-src_20070920.tar.gz patches: http://khibernation.sourceforge.net/download/release_20070920/kexec-tools/kexec-tools-patches_20070920.tar.gz binary: http://khibernation.sourceforge.net/download/release_20070920/kexec-tools/kexec_20070920.tar.gz 2. Memory image saving tool. Currently, the memory image saving is done through: "cp /proc/vmcore ". This will save all memory pages of original kernel including the free pages. Maybe the crash dump tool "makedumpfile" can be used for this, but it has not been tested. 3. Memory image restore tool. A simplest memory image restoring tool named "krestore" is implemented. It can be downloaded from the following URL: source: http://khibernation.sourceforge.net/download/release_20070920/krestore/krestore-src_20070920.tar.gz binary: http://khibernation.sourceforge.net/download/release_20070920/krestore/krestore_20070920.tar.gz Known issues: 1. The CONFIG_ACPI must be turned off to make kexec jump work. Because ACPI will put devices into low power state, the kexeced kernel can not be booted properly under it. This constrains can be eliminated by separating the suspend method and hibernate method of the devices as proposed earlier in the LKML. 2. The setup of hibernation/restore is fairly complex. I will continue working on simplifying. 3. Memory pages including free pages of kernel A are saved. I think the "makedumpfile" tool can be used to exclude "free pages", but I have not tested it. Now, only the i386 architecture is supported. The patch is based on Linux kernel 2.6.23-rc6-mm1, and has been tested on my IBM T42. Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patches (or download the source tar ball directly) and compile. 3. Download and compile the krestore tool. 4. Prepare 2 root partition used by kernel A and kernel B/C, referred as /dev/hda, /dev/hdb in following text. This is not strictly necessary, I use this scheme for testing during development. 5. Boot kernel compiled for normal usage (kernal A). 6. Load kernel compiled for hibernating/restore usage (kernel B) with kexec, the same kernel as that of 5 can be used if CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. The --elf64-core-headers should be specified in command line of kexec, because only the 64bit ELF is supported by krestore tool. For example, the shell command line can be as follow: kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --append="root=/dev/hdb single" 7. Jump to the hibernating kernel (kernel B) with following shell command line: kexec -j 8. In the hibernating kernel (kernel B), the memory image of hibernated kernel (kernel A) can be saved as follow:
[RFC][PATCH 0/2 -mm] kexec based hibernation -v3
Kexec base hibernation has some potential advantages over uswsusp and TuxOnIce (suspend2). Some most obvious advantages are: 1. The hibernation image size can exceed half of memory size easily. 2. The hibernation image can be written to and read from almost anywhere, such as USB disk, NFS. 3. It is possible to eliminate freezer from kexec based hibernation implementation. 4. Based on kexec/kdump implementation, the kernel code needed is less. This patch set implements the kexec based hibernation. The kernel functionality added are as follow: 1. Jumping between the kexeced kernel and the original kernel. This is used by hibernation to save/load necessary state in original kernel and jumping back to original kernel after restore the memory of original kernel. 2. Add writing support to /dev/oldmem. This is used by hibernation to restore the memory of original kernel. The hibernation procedure with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. 4. Save the memory image of kernel A through crash dump (such as cp /proc/vmcore ~). Save the jump back entry. 5. Shutdown or reboot The restore process with the patch set is as follow: 1. Boot a kernel C (crash dump enabled), the memory area used by kernel C must be a subset of memory area used by kernel B. 2. Restore the memory image of kernel A through /dev/oldmem. Restore the jump back entry. 3. Jump from kernel C back to kernel A 4. Continue work under kernel A The following user-space tools are needed to implement hibernation and restore. 1. kexec-tools needs to be patched to support kexec jump. The patches and the precompiled kexec can be download from the following URL: source: http://khibernation.sourceforge.net/download/release_20070920/kexec-tools/kexec-tools-src_20070920.tar.gz patches: http://khibernation.sourceforge.net/download/release_20070920/kexec-tools/kexec-tools-patches_20070920.tar.gz binary: http://khibernation.sourceforge.net/download/release_20070920/kexec-tools/kexec_20070920.tar.gz 2. Memory image saving tool. Currently, the memory image saving is done through: cp /proc/vmcore image file. This will save all memory pages of original kernel including the free pages. Maybe the crash dump tool makedumpfile can be used for this, but it has not been tested. 3. Memory image restore tool. A simplest memory image restoring tool named krestore is implemented. It can be downloaded from the following URL: source: http://khibernation.sourceforge.net/download/release_20070920/krestore/krestore-src_20070920.tar.gz binary: http://khibernation.sourceforge.net/download/release_20070920/krestore/krestore_20070920.tar.gz Known issues: 1. The CONFIG_ACPI must be turned off to make kexec jump work. Because ACPI will put devices into low power state, the kexeced kernel can not be booted properly under it. This constrains can be eliminated by separating the suspend method and hibernate method of the devices as proposed earlier in the LKML. 2. The setup of hibernation/restore is fairly complex. I will continue working on simplifying. 3. Memory pages including free pages of kernel A are saved. I think the makedumpfile tool can be used to exclude free pages, but I have not tested it. Now, only the i386 architecture is supported. The patch is based on Linux kernel 2.6.23-rc6-mm1, and has been tested on my IBM T42. Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patches (or download the source tar ball directly) and compile. 3. Download and compile the krestore tool. 4. Prepare 2 root partition used by kernel A and kernel B/C, referred as /dev/hda, /dev/hdb in following text. This is not strictly necessary, I use this scheme for testing during development. 5. Boot kernel compiled for normal usage (kernal A). 6. Load kernel compiled for hibernating/restore usage (kernel B) with kexec, the same kernel as that of 5 can be used if CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected. The --elf64-core-headers should be specified in command line of kexec, because only the 64bit ELF is supported by krestore tool. For example, the shell command line can be as follow: kexec -p -n /boot/bzImage --mem-min=0x10 --mem-max=0xff --elf64-core-headers --append=root=/dev/hdb single 7. Jump to the hibernating kernel (kernel B) with following shell command line: kexec -j 8. In the hibernating kernel (kernel B), the memory image of hibernated kernel (kernel A) can be saved as follow: cp
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation
Huang, Ying wrote: On Mon, 2007-08-27 at 09:28 +0800, Hu, Fenghua wrote: One quick question is, can it improve hiberation/wakeup time? In general, for kexec based hibernation, what increases hibernation/wakeup time: - One extra Linux boot is needed to hibernate and wakeup. What decreases hibernation/wakeup time: - Most hibernation/wakeup work is done in full functional user space program, so it is possible to do some optimization, such as parallel compression. - It does not have to reclaim pagecache before suspend? - It does not have to restore working set afterwards? (You could do this to reduce image size, of course, but it can be optional which is nice). So, I think the kexec based hibernation may be slower than original implementation in general. In this prototype implementation, the hibernation/wakeup time is much longer than original hibernation/wakeup implementation. But it has much to be optimized and I think it can approach the speed of the original implementation after optimization. Also, don't just look at the time to do a simple suspend/resume cycle, but the full cost of going from working state to working state (eg. grep a kernel tree or two!). Although the kexec details are out of my league, I really like everything about the concept :) Nice work. -- SUSE Labs, Novell Inc. - 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/
Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation
Huang, Ying wrote: On Mon, 2007-08-27 at 09:28 +0800, Hu, Fenghua wrote: One quick question is, can it improve hiberation/wakeup time? In general, for kexec based hibernation, what increases hibernation/wakeup time: - One extra Linux boot is needed to hibernate and wakeup. What decreases hibernation/wakeup time: - Most hibernation/wakeup work is done in full functional user space program, so it is possible to do some optimization, such as parallel compression. - It does not have to reclaim pagecache before suspend? - It does not have to restore working set afterwards? (You could do this to reduce image size, of course, but it can be optional which is nice). So, I think the kexec based hibernation may be slower than original implementation in general. In this prototype implementation, the hibernation/wakeup time is much longer than original hibernation/wakeup implementation. But it has much to be optimized and I think it can approach the speed of the original implementation after optimization. Also, don't just look at the time to do a simple suspend/resume cycle, but the full cost of going from working state to working state (eg. grep a kernel tree or two!). Although the kexec details are out of my league, I really like everything about the concept :) Nice work. -- SUSE Labs, Novell Inc. - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
On Mon, 2007-08-27 at 13:15 +, Pavel Machek wrote: > Hi! > > > >> > Does this make sense? > > >> > > >> Yes, this is a sensible optimization. But I think it may be better to > > >> make bootloader load kernel D directly into a specified memory location. > > >> For example, we can add a option to "kernel" command of grub. > > >> > > >> And, I think we can do more in bootloader. Such as we can prepare > > >> two > > > > > > Yes, that would be nice. > > > > > > It will mean quite a bit of work, but I guess it should be the long > > > term goal. Loading restore kernel directly from bootloader means: > > > > > > 1) it is fast -- no need to boot another kernel > > > > > > 2) it is "classical" way of doing things > > > > > > On the other hand, we loose flexibility that way: > > > > > > 1) it locks you onto one bootloader > > > > > > 2) you no longer have userland there to do uncompression, decryption, > > > etc.. > > > > True although for the uncompression and decryption those aren't exactly > > foreign > > requirements for bootloaders. > > Well, uncompression yes, but crypto? What is that, some kind of > trusted computing thingie? > > We do RSA for uswsusp, that may be a bit of problem for a bootloader, > but I'm glad bootloaders are bloated already :-). As far as I know, the grub 2.0 uses a modular implementation scheme. That is, every OS loader (Multi-boot, Linux, FreeBSD etc), partition table, file system is implemented as a module, and these modules can be statically linked into the final image. So I think the hibernation image loading can be implemented in grub 2.0 in a manageable way. :) Best Regards, Huang Ying - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
Hi! > >> > Does this make sense? > >> > >> Yes, this is a sensible optimization. But I think it may be better to > >> make bootloader load kernel D directly into a specified memory location. > >> For example, we can add a option to "kernel" command of grub. > >> > >> And, I think we can do more in bootloader. Such as we can prepare > >> two > > > > Yes, that would be nice. > > > > It will mean quite a bit of work, but I guess it should be the long > > term goal. Loading restore kernel directly from bootloader means: > > > > 1) it is fast -- no need to boot another kernel > > > > 2) it is "classical" way of doing things > > > > On the other hand, we loose flexibility that way: > > > > 1) it locks you onto one bootloader > > > > 2) you no longer have userland there to do uncompression, decryption, > > etc.. > > True although for the uncompression and decryption those aren't exactly > foreign > requirements for bootloaders. Well, uncompression yes, but crypto? What is that, some kind of trusted computing thingie? We do RSA for uswsusp, that may be a bit of problem for a bootloader, but I'm glad bootloaders are bloated already :-). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > >> > Does this make sense? >> >> Yes, this is a sensible optimization. But I think it may be better to >> make bootloader load kernel D directly into a specified memory location. >> For example, we can add a option to "kernel" command of grub. >> >> And, I think we can do more in bootloader. Such as we can prepare >> two > > Yes, that would be nice. > > It will mean quite a bit of work, but I guess it should be the long > term goal. Loading restore kernel directly from bootloader means: > > 1) it is fast -- no need to boot another kernel > > 2) it is "classical" way of doing things > > On the other hand, we loose flexibility that way: > > 1) it locks you onto one bootloader > > 2) you no longer have userland there to do uncompression, decryption, > etc.. True although for the uncompression and decryption those aren't exactly foreign requirements for bootloaders. Eric - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
Hi! > > Does this make sense? > > Yes, this is a sensible optimization. But I think it may be better to > make bootloader load kernel D directly into a specified memory location. > For example, we can add a option to "kernel" command of grub. > > And, I think we can do more in bootloader. Such as we can prepare > two Yes, that would be nice. It will mean quite a bit of work, but I guess it should be the long term goal. Loading restore kernel directly from bootloader means: 1) it is fast -- no need to boot another kernel 2) it is "classical" way of doing things On the other hand, we loose flexibility that way: 1) it locks you onto one bootloader 2) you no longer have userland there to do uncompression, decryption, etc.. Pave -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
On Mon, Aug 27, 2007 at 02:18:49PM +0800, Huang, Ying wrote: [..] > > > > If one compiles the kernel C to boot from reserved memory area (subset > > of memory area used by kernel B), then I can skip the step of kexecing > > from C to D? (COFIG_PHYSICAL_START) > > Yes. I think so. > > > Alternatively, can we give hint to kernel C to run from a specified address > > at run time with the help of command line parameters. What I mean > > boot-loader > > can load the kernel at any address, but kernel will move itself to run > > from a different location depending on command line parameter. For example, > > let say kernel_run_addr = 0x100. This parameter will tell the kernel > > to move itself to 16MB address and run from there. I think it can be made > > to work with little work in existing setup of relocatable kernel. > > > > Kernel run address can be put by some user space script which will save > > the hibernated image of original kernel. So after saving the /proc/vmcore, > > script can modify the boot loader config file to append the right > > command line to the kernel (kernel_run_addr). > > > > After hibernation, user will shutdown/reboot. Next time the kernel boots > > it will load at 16MB addr (because of kernel_run_addr) and then it can > > restore the previously saved image. > > > > We shall have to get rid of (kernel_run_addr) parameter from command > > line while resuming. One can restore the image (krestore) and then edit > > the boot loader config file to get rid of command line param, > > kernel_run_addr. > > > > In this scheme, with the help of relocatable kernel, we can use a single > > kernel for everything. (A, B, C, D). We will also avoid additional kexec > > from kernel C to kernel D. > > > > I think in the long run we shall have to work out so that a user does > > not have to maintain multiple kernels. > > Only one relocatable kernel image is needed. In fact, I use one > relocatable kernel image in testing during development. > > > Does this make sense? > > Yes, this is a sensible optimization. But I think it may be better to > make bootloader load kernel D directly into a specified memory location. > For example, we can add a option to "kernel" command of grub. > IIUC, you mean a command line option which is parsed by boot-loader and then boot-loader loads the kernel at user specified address? I think it might not be a very good idea as hibernation becomes boot-loader dependent scheme. How many boot-loaders will one modify and hibernation will not work with older versions of boot-loader. I think it is better to make kernel relocate to user specified address and keep hibernation mechanism independent of specific boot-loader(grup, lilo,...) and boot-loader version. Thanks Vivek - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
On Mon, 2007-08-27 at 10:30 +0530, Vivek Goyal wrote: > On Mon, Aug 27, 2007 at 09:14:05AM +0800, Huang, Ying wrote: > > Kexec base hibernation has some potential advantages over uswsusp and > > TuxOnIce (suspend2). Some most obvious advantages are: > > > > 1. The hibernation image size can exceed half of memory size easily. > > > > 2. The hibernation image can be written to and read from almost > >anywhere, such as USB disk, NFS. > > > > 3. It is possible to eliminate freezer from kexec based hibernation > >implementation. > > > > 4. Based on kexec/kdump implementation, the kernel code needed is > >less. > > > > > > This patch set implements a prototype of kexec based hibernation. The > > kernel functionalities added are as follow: > > > > 1. Jumping from kexeced kernel back to original kernel. This is used > >by hibernation to save/load necessary state in original kernel and > >jumping back to original kernel after restore the memory of > >original kernel. > > > > 2. Add writing support to /dev/oldmem. This is used by hibernation to > >restore the memory of original kernel. > > > > > > The hibernation process with the patch set is as follow: > > > > 1. Boot a kernel A > > > > 2. Work under kernel A > > > > 3. Kexec another kernel B (crash dump enabled) in kernel A. > > > > 4. Save the memory image of kernel A through crash dump (such as "cp > >/proc/vmcore ~"). Save the "jump buffer pfn". > > > > 5. Shutdown or reboot > > > > > > The restore process with the patch set is as follow: > > > > 1. Boot a kernel C > > > > 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory > >area used by kernel D must be a subset of memory area used by > >kernel B. > > > > If one compiles the kernel C to boot from reserved memory area (subset > of memory area used by kernel B), then I can skip the step of kexecing > from C to D? (COFIG_PHYSICAL_START) Yes. I think so. > Alternatively, can we give hint to kernel C to run from a specified address > at run time with the help of command line parameters. What I mean boot-loader > can load the kernel at any address, but kernel will move itself to run > from a different location depending on command line parameter. For example, > let say kernel_run_addr = 0x100. This parameter will tell the kernel > to move itself to 16MB address and run from there. I think it can be made > to work with little work in existing setup of relocatable kernel. > > Kernel run address can be put by some user space script which will save > the hibernated image of original kernel. So after saving the /proc/vmcore, > script can modify the boot loader config file to append the right > command line to the kernel (kernel_run_addr). > > After hibernation, user will shutdown/reboot. Next time the kernel boots > it will load at 16MB addr (because of kernel_run_addr) and then it can > restore the previously saved image. > > We shall have to get rid of (kernel_run_addr) parameter from command > line while resuming. One can restore the image (krestore) and then edit > the boot loader config file to get rid of command line param, kernel_run_addr. > > In this scheme, with the help of relocatable kernel, we can use a single > kernel for everything. (A, B, C, D). We will also avoid additional kexec > from kernel C to kernel D. > > I think in the long run we shall have to work out so that a user does > not have to maintain multiple kernels. Only one relocatable kernel image is needed. In fact, I use one relocatable kernel image in testing during development. > Does this make sense? Yes, this is a sensible optimization. But I think it may be better to make bootloader load kernel D directly into a specified memory location. For example, we can add a option to "kernel" command of grub. And, I think we can do more in bootloader. Such as we can prepare two kernel command line for one grub menu item, one for normal kernel, the other for restore kernel. After hibernating successfully, the effective kernel command line is switched. Best Regards, Huang Ying - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
On Mon, 2007-08-27 at 10:30 +0530, Vivek Goyal wrote: On Mon, Aug 27, 2007 at 09:14:05AM +0800, Huang, Ying wrote: Kexec base hibernation has some potential advantages over uswsusp and TuxOnIce (suspend2). Some most obvious advantages are: 1. The hibernation image size can exceed half of memory size easily. 2. The hibernation image can be written to and read from almost anywhere, such as USB disk, NFS. 3. It is possible to eliminate freezer from kexec based hibernation implementation. 4. Based on kexec/kdump implementation, the kernel code needed is less. This patch set implements a prototype of kexec based hibernation. The kernel functionalities added are as follow: 1. Jumping from kexeced kernel back to original kernel. This is used by hibernation to save/load necessary state in original kernel and jumping back to original kernel after restore the memory of original kernel. 2. Add writing support to /dev/oldmem. This is used by hibernation to restore the memory of original kernel. The hibernation process with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. 4. Save the memory image of kernel A through crash dump (such as cp /proc/vmcore ~). Save the jump buffer pfn. 5. Shutdown or reboot The restore process with the patch set is as follow: 1. Boot a kernel C 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory area used by kernel D must be a subset of memory area used by kernel B. If one compiles the kernel C to boot from reserved memory area (subset of memory area used by kernel B), then I can skip the step of kexecing from C to D? (COFIG_PHYSICAL_START) Yes. I think so. Alternatively, can we give hint to kernel C to run from a specified address at run time with the help of command line parameters. What I mean boot-loader can load the kernel at any address, but kernel will move itself to run from a different location depending on command line parameter. For example, let say kernel_run_addr = 0x100. This parameter will tell the kernel to move itself to 16MB address and run from there. I think it can be made to work with little work in existing setup of relocatable kernel. Kernel run address can be put by some user space script which will save the hibernated image of original kernel. So after saving the /proc/vmcore, script can modify the boot loader config file to append the right command line to the kernel (kernel_run_addr). After hibernation, user will shutdown/reboot. Next time the kernel boots it will load at 16MB addr (because of kernel_run_addr) and then it can restore the previously saved image. We shall have to get rid of (kernel_run_addr) parameter from command line while resuming. One can restore the image (krestore) and then edit the boot loader config file to get rid of command line param, kernel_run_addr. In this scheme, with the help of relocatable kernel, we can use a single kernel for everything. (A, B, C, D). We will also avoid additional kexec from kernel C to kernel D. I think in the long run we shall have to work out so that a user does not have to maintain multiple kernels. Only one relocatable kernel image is needed. In fact, I use one relocatable kernel image in testing during development. Does this make sense? Yes, this is a sensible optimization. But I think it may be better to make bootloader load kernel D directly into a specified memory location. For example, we can add a option to kernel command of grub. And, I think we can do more in bootloader. Such as we can prepare two kernel command line for one grub menu item, one for normal kernel, the other for restore kernel. After hibernating successfully, the effective kernel command line is switched. Best Regards, Huang Ying - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
On Mon, Aug 27, 2007 at 02:18:49PM +0800, Huang, Ying wrote: [..] If one compiles the kernel C to boot from reserved memory area (subset of memory area used by kernel B), then I can skip the step of kexecing from C to D? (COFIG_PHYSICAL_START) Yes. I think so. Alternatively, can we give hint to kernel C to run from a specified address at run time with the help of command line parameters. What I mean boot-loader can load the kernel at any address, but kernel will move itself to run from a different location depending on command line parameter. For example, let say kernel_run_addr = 0x100. This parameter will tell the kernel to move itself to 16MB address and run from there. I think it can be made to work with little work in existing setup of relocatable kernel. Kernel run address can be put by some user space script which will save the hibernated image of original kernel. So after saving the /proc/vmcore, script can modify the boot loader config file to append the right command line to the kernel (kernel_run_addr). After hibernation, user will shutdown/reboot. Next time the kernel boots it will load at 16MB addr (because of kernel_run_addr) and then it can restore the previously saved image. We shall have to get rid of (kernel_run_addr) parameter from command line while resuming. One can restore the image (krestore) and then edit the boot loader config file to get rid of command line param, kernel_run_addr. In this scheme, with the help of relocatable kernel, we can use a single kernel for everything. (A, B, C, D). We will also avoid additional kexec from kernel C to kernel D. I think in the long run we shall have to work out so that a user does not have to maintain multiple kernels. Only one relocatable kernel image is needed. In fact, I use one relocatable kernel image in testing during development. Does this make sense? Yes, this is a sensible optimization. But I think it may be better to make bootloader load kernel D directly into a specified memory location. For example, we can add a option to kernel command of grub. IIUC, you mean a command line option which is parsed by boot-loader and then boot-loader loads the kernel at user specified address? I think it might not be a very good idea as hibernation becomes boot-loader dependent scheme. How many boot-loaders will one modify and hibernation will not work with older versions of boot-loader. I think it is better to make kernel relocate to user specified address and keep hibernation mechanism independent of specific boot-loader(grup, lilo,...) and boot-loader version. Thanks Vivek - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
Hi! Does this make sense? Yes, this is a sensible optimization. But I think it may be better to make bootloader load kernel D directly into a specified memory location. For example, we can add a option to kernel command of grub. And, I think we can do more in bootloader. Such as we can prepare two Yes, that would be nice. It will mean quite a bit of work, but I guess it should be the long term goal. Loading restore kernel directly from bootloader means: 1) it is fast -- no need to boot another kernel 2) it is classical way of doing things On the other hand, we loose flexibility that way: 1) it locks you onto one bootloader 2) you no longer have userland there to do uncompression, decryption, etc.. Pave -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
Pavel Machek [EMAIL PROTECTED] writes: Hi! Does this make sense? Yes, this is a sensible optimization. But I think it may be better to make bootloader load kernel D directly into a specified memory location. For example, we can add a option to kernel command of grub. And, I think we can do more in bootloader. Such as we can prepare two Yes, that would be nice. It will mean quite a bit of work, but I guess it should be the long term goal. Loading restore kernel directly from bootloader means: 1) it is fast -- no need to boot another kernel 2) it is classical way of doing things On the other hand, we loose flexibility that way: 1) it locks you onto one bootloader 2) you no longer have userland there to do uncompression, decryption, etc.. True although for the uncompression and decryption those aren't exactly foreign requirements for bootloaders. Eric - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
Hi! Does this make sense? Yes, this is a sensible optimization. But I think it may be better to make bootloader load kernel D directly into a specified memory location. For example, we can add a option to kernel command of grub. And, I think we can do more in bootloader. Such as we can prepare two Yes, that would be nice. It will mean quite a bit of work, but I guess it should be the long term goal. Loading restore kernel directly from bootloader means: 1) it is fast -- no need to boot another kernel 2) it is classical way of doing things On the other hand, we loose flexibility that way: 1) it locks you onto one bootloader 2) you no longer have userland there to do uncompression, decryption, etc.. True although for the uncompression and decryption those aren't exactly foreign requirements for bootloaders. Well, uncompression yes, but crypto? What is that, some kind of trusted computing thingie? We do RSA for uswsusp, that may be a bit of problem for a bootloader, but I'm glad bootloaders are bloated already :-). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
On Mon, 2007-08-27 at 13:15 +, Pavel Machek wrote: Hi! Does this make sense? Yes, this is a sensible optimization. But I think it may be better to make bootloader load kernel D directly into a specified memory location. For example, we can add a option to kernel command of grub. And, I think we can do more in bootloader. Such as we can prepare two Yes, that would be nice. It will mean quite a bit of work, but I guess it should be the long term goal. Loading restore kernel directly from bootloader means: 1) it is fast -- no need to boot another kernel 2) it is classical way of doing things On the other hand, we loose flexibility that way: 1) it locks you onto one bootloader 2) you no longer have userland there to do uncompression, decryption, etc.. True although for the uncompression and decryption those aren't exactly foreign requirements for bootloaders. Well, uncompression yes, but crypto? What is that, some kind of trusted computing thingie? We do RSA for uswsusp, that may be a bit of problem for a bootloader, but I'm glad bootloaders are bloated already :-). As far as I know, the grub 2.0 uses a modular implementation scheme. That is, every OS loader (Multi-boot, Linux, FreeBSD etc), partition table, file system is implemented as a module, and these modules can be statically linked into the final image. So I think the hibernation image loading can be implemented in grub 2.0 in a manageable way. :) Best Regards, Huang Ying - 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/
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
On Mon, Aug 27, 2007 at 09:14:05AM +0800, Huang, Ying wrote: > Kexec base hibernation has some potential advantages over uswsusp and > TuxOnIce (suspend2). Some most obvious advantages are: > > 1. The hibernation image size can exceed half of memory size easily. > > 2. The hibernation image can be written to and read from almost >anywhere, such as USB disk, NFS. > > 3. It is possible to eliminate freezer from kexec based hibernation >implementation. > > 4. Based on kexec/kdump implementation, the kernel code needed is >less. > > > This patch set implements a prototype of kexec based hibernation. The > kernel functionalities added are as follow: > > 1. Jumping from kexeced kernel back to original kernel. This is used >by hibernation to save/load necessary state in original kernel and >jumping back to original kernel after restore the memory of >original kernel. > > 2. Add writing support to /dev/oldmem. This is used by hibernation to >restore the memory of original kernel. > > > The hibernation process with the patch set is as follow: > > 1. Boot a kernel A > > 2. Work under kernel A > > 3. Kexec another kernel B (crash dump enabled) in kernel A. > > 4. Save the memory image of kernel A through crash dump (such as "cp >/proc/vmcore ~"). Save the "jump buffer pfn". > > 5. Shutdown or reboot > > > The restore process with the patch set is as follow: > > 1. Boot a kernel C > > 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory >area used by kernel D must be a subset of memory area used by >kernel B. > If one compiles the kernel C to boot from reserved memory area (subset of memory area used by kernel B), then I can skip the step of kexecing from C to D? (COFIG_PHYSICAL_START) Alternatively, can we give hint to kernel C to run from a specified address at run time with the help of command line parameters. What I mean boot-loader can load the kernel at any address, but kernel will move itself to run from a different location depending on command line parameter. For example, let say kernel_run_addr = 0x100. This parameter will tell the kernel to move itself to 16MB address and run from there. I think it can be made to work with little work in existing setup of relocatable kernel. Kernel run address can be put by some user space script which will save the hibernated image of original kernel. So after saving the /proc/vmcore, script can modify the boot loader config file to append the right command line to the kernel (kernel_run_addr). After hibernation, user will shutdown/reboot. Next time the kernel boots it will load at 16MB addr (because of kernel_run_addr) and then it can restore the previously saved image. We shall have to get rid of (kernel_run_addr) parameter from command line while resuming. One can restore the image (krestore) and then edit the boot loader config file to get rid of command line param, kernel_run_addr. In this scheme, with the help of relocatable kernel, we can use a single kernel for everything. (A, B, C, D). We will also avoid additional kexec from kernel C to kernel D. I think in the long run we shall have to work out so that a user does not have to maintain multiple kernels. Does this make sense? Thanks Vivek - 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/
RE: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation
On Mon, 2007-08-27 at 09:28 +0800, Hu, Fenghua wrote: > One quick question is, can it improve hiberation/wakeup time? In general, for kexec based hibernation, what increases hibernation/wakeup time: - One extra Linux boot is needed to hibernate and wakeup. What decreases hibernation/wakeup time: - Most hibernation/wakeup work is done in full functional user space program, so it is possible to do some optimization, such as parallel compression. So, I think the kexec based hibernation may be slower than original implementation in general. In this prototype implementation, the hibernation/wakeup time is much longer than original hibernation/wakeup implementation. But it has much to be optimized and I think it can approach the speed of the original implementation after optimization. For example, the hibernation image is an ordinary ELF file, so it can be loaded by bootloader directly. Best Regards, Huang Ying > Best regards > Hu, Fenghua > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Huang, Ying > Sent: 2007年8月27日 9:14 > To: Eric W. Biederman; Pavel Machek; [EMAIL PROTECTED]; Andrew Morton; Jeremy > Maitin-Shepard; Alan Stern > Cc: [EMAIL PROTECTED]; Kexec Mailing List; linux-kernel@vger.kernel.org > Subject: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation > > Kexec base hibernation has some potential advantages over uswsusp and > TuxOnIce (suspend2). Some most obvious advantages are: > > 1. The hibernation image size can exceed half of memory size easily. > > 2. The hibernation image can be written to and read from almost >anywhere, such as USB disk, NFS. > > 3. It is possible to eliminate freezer from kexec based hibernation >implementation. > > 4. Based on kexec/kdump implementation, the kernel code needed is >less. > > > This patch set implements a prototype of kexec based hibernation. The > kernel functionalities added are as follow: > > 1. Jumping from kexeced kernel back to original kernel. This is used >by hibernation to save/load necessary state in original kernel and >jumping back to original kernel after restore the memory of >original kernel. > > 2. Add writing support to /dev/oldmem. This is used by hibernation to >restore the memory of original kernel. > > > The hibernation process with the patch set is as follow: > > 1. Boot a kernel A > > 2. Work under kernel A > > 3. Kexec another kernel B (crash dump enabled) in kernel A. > > 4. Save the memory image of kernel A through crash dump (such as "cp >/proc/vmcore ‾"). Save the "jump buffer pfn". > > 5. Shutdown or reboot > > > The restore process with the patch set is as follow: > > 1. Boot a kernel C > > 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory >area used by kernel D must be a subset of memory area used by >kernel B. > > 3. Restore the memory image of kernel A through /dev/oldmem. Restore >the "jump buffer pfn". > > 4. Jump from kernel D back to kernel A > > 5. Continue work under kernel A > > > The following user-space tools are needed to implement hibernation and > restore. > > 1. kexec-tools needs to be patched to support kexec jump. The patch is >attached in this mail. The precompiled kexec can be download from: >http://linux-mcr700.sourceforge.net/kjump/kexec > > 2. Memory image saving tool. Currently, the memory image saving is >done through: "cp /proc/vmcore ". This will save all >memory pages of original kernel including the free pages. Maybe the >crash dump tool "makedumpfile" can be used for this, but it has not >been tested. > > 3. Memory image restore tool. A simplest memory image restoring tool >named "krestore" is implemented. It can be downloaded from >following URL: >source: http://linux-mcr700.sourceforge.net/kjump/krestore.tar.gz >binary: http://linux-mcr700.sourceforge.net/kjump/krestore > > > Known issues: > > 1. The kernel B run as a crashdump kernel in reserved memory >region. This is the biggest constrains of the patch set and planed >to be eliminated in the future version. That is, instead of >reserving memory region previously, the needed memory region is >backupped before kexec and restored after jumping back. > > 2. Another constrains of the patch set is that the CONFIG_ACPI must be >turned off to make kexec jump work. Because ACPI will put devices >into low power state, the kexeced kernel can not be booted properly >under it. This constrains can be eliminated by separating the >suspend method and
RE: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation
One quick question is, can it improve hiberation/wakeup time? Best regards Hu, Fenghua -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Huang, Ying Sent: 2007年8月27日 9:14 To: Eric W. Biederman; Pavel Machek; [EMAIL PROTECTED]; Andrew Morton; Jeremy Maitin-Shepard; Alan Stern Cc: [EMAIL PROTECTED]; Kexec Mailing List; linux-kernel@vger.kernel.org Subject: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation Kexec base hibernation has some potential advantages over uswsusp and TuxOnIce (suspend2). Some most obvious advantages are: 1. The hibernation image size can exceed half of memory size easily. 2. The hibernation image can be written to and read from almost anywhere, such as USB disk, NFS. 3. It is possible to eliminate freezer from kexec based hibernation implementation. 4. Based on kexec/kdump implementation, the kernel code needed is less. This patch set implements a prototype of kexec based hibernation. The kernel functionalities added are as follow: 1. Jumping from kexeced kernel back to original kernel. This is used by hibernation to save/load necessary state in original kernel and jumping back to original kernel after restore the memory of original kernel. 2. Add writing support to /dev/oldmem. This is used by hibernation to restore the memory of original kernel. The hibernation process with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. 4. Save the memory image of kernel A through crash dump (such as "cp /proc/vmcore ~"). Save the "jump buffer pfn". 5. Shutdown or reboot The restore process with the patch set is as follow: 1. Boot a kernel C 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory area used by kernel D must be a subset of memory area used by kernel B. 3. Restore the memory image of kernel A through /dev/oldmem. Restore the "jump buffer pfn". 4. Jump from kernel D back to kernel A 5. Continue work under kernel A The following user-space tools are needed to implement hibernation and restore. 1. kexec-tools needs to be patched to support kexec jump. The patch is attached in this mail. The precompiled kexec can be download from: http://linux-mcr700.sourceforge.net/kjump/kexec 2. Memory image saving tool. Currently, the memory image saving is done through: "cp /proc/vmcore ". This will save all memory pages of original kernel including the free pages. Maybe the crash dump tool "makedumpfile" can be used for this, but it has not been tested. 3. Memory image restore tool. A simplest memory image restoring tool named "krestore" is implemented. It can be downloaded from following URL: source: http://linux-mcr700.sourceforge.net/kjump/krestore.tar.gz binary: http://linux-mcr700.sourceforge.net/kjump/krestore Known issues: 1. The kernel B run as a crashdump kernel in reserved memory region. This is the biggest constrains of the patch set and planed to be eliminated in the future version. That is, instead of reserving memory region previously, the needed memory region is backupped before kexec and restored after jumping back. 2. Another constrains of the patch set is that the CONFIG_ACPI must be turned off to make kexec jump work. Because ACPI will put devices into low power state, the kexeced kernel can not be booted properly under it. This constrains can be eliminated by separating the suspend method and hibernate method of the devices as proposed earlier in the LKML. 3. The setup of hibernation/restore is fairly complex. I will continue working on simplifying. 4. Memory pages including free pages of kernel A are saved. I think the "makedumpfile" tool can be used to exclude "free pages", but I have not tested it. Now, only the i386 architecture is supported. The patch is based on Linux kernel 2.6.23-rc3-mm1, and has been tested on my IBM T42. Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patch and compile. The kexec-tools kjump patch is appended with the mail. The precompiled kexec can be download from: http://linux-mcr700.sourceforge.net/kjump/kexec 3. Download and compile the krestore tool. The source code and precompiled binary can be downloaded from the following URL: source: http://linux-mcr700.sourceforge.net/kjump/krestore.tar.gz binary: http://linux-mcr700.sourceforge.net/kjump/krestore 4. Prepare 3 root partition used by kernel A, kernel B, kernel C, refered as /dev/hda
[RFC][PATCH 0/2 -mm] kexec based hibernation
Kexec base hibernation has some potential advantages over uswsusp and TuxOnIce (suspend2). Some most obvious advantages are: 1. The hibernation image size can exceed half of memory size easily. 2. The hibernation image can be written to and read from almost anywhere, such as USB disk, NFS. 3. It is possible to eliminate freezer from kexec based hibernation implementation. 4. Based on kexec/kdump implementation, the kernel code needed is less. This patch set implements a prototype of kexec based hibernation. The kernel functionalities added are as follow: 1. Jumping from kexeced kernel back to original kernel. This is used by hibernation to save/load necessary state in original kernel and jumping back to original kernel after restore the memory of original kernel. 2. Add writing support to /dev/oldmem. This is used by hibernation to restore the memory of original kernel. The hibernation process with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. 4. Save the memory image of kernel A through crash dump (such as "cp /proc/vmcore ~"). Save the "jump buffer pfn". 5. Shutdown or reboot The restore process with the patch set is as follow: 1. Boot a kernel C 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory area used by kernel D must be a subset of memory area used by kernel B. 3. Restore the memory image of kernel A through /dev/oldmem. Restore the "jump buffer pfn". 4. Jump from kernel D back to kernel A 5. Continue work under kernel A The following user-space tools are needed to implement hibernation and restore. 1. kexec-tools needs to be patched to support kexec jump. The patch is attached in this mail. The precompiled kexec can be download from: http://linux-mcr700.sourceforge.net/kjump/kexec 2. Memory image saving tool. Currently, the memory image saving is done through: "cp /proc/vmcore ". This will save all memory pages of original kernel including the free pages. Maybe the crash dump tool "makedumpfile" can be used for this, but it has not been tested. 3. Memory image restore tool. A simplest memory image restoring tool named "krestore" is implemented. It can be downloaded from following URL: source: http://linux-mcr700.sourceforge.net/kjump/krestore.tar.gz binary: http://linux-mcr700.sourceforge.net/kjump/krestore Known issues: 1. The kernel B run as a crashdump kernel in reserved memory region. This is the biggest constrains of the patch set and planed to be eliminated in the future version. That is, instead of reserving memory region previously, the needed memory region is backupped before kexec and restored after jumping back. 2. Another constrains of the patch set is that the CONFIG_ACPI must be turned off to make kexec jump work. Because ACPI will put devices into low power state, the kexeced kernel can not be booted properly under it. This constrains can be eliminated by separating the suspend method and hibernate method of the devices as proposed earlier in the LKML. 3. The setup of hibernation/restore is fairly complex. I will continue working on simplifying. 4. Memory pages including free pages of kernel A are saved. I think the "makedumpfile" tool can be used to exclude "free pages", but I have not tested it. Now, only the i386 architecture is supported. The patch is based on Linux kernel 2.6.23-rc3-mm1, and has been tested on my IBM T42. Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patch and compile. The kexec-tools kjump patch is appended with the mail. The precompiled kexec can be download from: http://linux-mcr700.sourceforge.net/kjump/kexec 3. Download and compile the krestore tool. The source code and precompiled binary can be downloaded from the following URL: source: http://linux-mcr700.sourceforge.net/kjump/krestore.tar.gz binary: http://linux-mcr700.sourceforge.net/kjump/krestore 4. Prepare 3 root partition used by kernel A, kernel B, kernel C, refered as /dev/hda, /dev/hdb, /dev/hdc in following text. This is not strictly necessary, I use this scheme for testing during development. 5. Boot kernel compiled for normal usage (kernel A), the reserved crash kernel memory region must be added to kernel command line as follow: crashkernel=M@M Where, should be replaced by the real memory size and position. I use [EMAIL PROTECTED] in my testing. 6. Load kernel compiled for hibernating usage (kernel B) as a crashdump kernel with kexec, the same kernel as that of 5 can be
[RFC][PATCH 0/2 -mm] kexec based hibernation
Kexec base hibernation has some potential advantages over uswsusp and TuxOnIce (suspend2). Some most obvious advantages are: 1. The hibernation image size can exceed half of memory size easily. 2. The hibernation image can be written to and read from almost anywhere, such as USB disk, NFS. 3. It is possible to eliminate freezer from kexec based hibernation implementation. 4. Based on kexec/kdump implementation, the kernel code needed is less. This patch set implements a prototype of kexec based hibernation. The kernel functionalities added are as follow: 1. Jumping from kexeced kernel back to original kernel. This is used by hibernation to save/load necessary state in original kernel and jumping back to original kernel after restore the memory of original kernel. 2. Add writing support to /dev/oldmem. This is used by hibernation to restore the memory of original kernel. The hibernation process with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. 4. Save the memory image of kernel A through crash dump (such as cp /proc/vmcore ~). Save the jump buffer pfn. 5. Shutdown or reboot The restore process with the patch set is as follow: 1. Boot a kernel C 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory area used by kernel D must be a subset of memory area used by kernel B. 3. Restore the memory image of kernel A through /dev/oldmem. Restore the jump buffer pfn. 4. Jump from kernel D back to kernel A 5. Continue work under kernel A The following user-space tools are needed to implement hibernation and restore. 1. kexec-tools needs to be patched to support kexec jump. The patch is attached in this mail. The precompiled kexec can be download from: http://linux-mcr700.sourceforge.net/kjump/kexec 2. Memory image saving tool. Currently, the memory image saving is done through: cp /proc/vmcore image file. This will save all memory pages of original kernel including the free pages. Maybe the crash dump tool makedumpfile can be used for this, but it has not been tested. 3. Memory image restore tool. A simplest memory image restoring tool named krestore is implemented. It can be downloaded from following URL: source: http://linux-mcr700.sourceforge.net/kjump/krestore.tar.gz binary: http://linux-mcr700.sourceforge.net/kjump/krestore Known issues: 1. The kernel B run as a crashdump kernel in reserved memory region. This is the biggest constrains of the patch set and planed to be eliminated in the future version. That is, instead of reserving memory region previously, the needed memory region is backupped before kexec and restored after jumping back. 2. Another constrains of the patch set is that the CONFIG_ACPI must be turned off to make kexec jump work. Because ACPI will put devices into low power state, the kexeced kernel can not be booted properly under it. This constrains can be eliminated by separating the suspend method and hibernate method of the devices as proposed earlier in the LKML. 3. The setup of hibernation/restore is fairly complex. I will continue working on simplifying. 4. Memory pages including free pages of kernel A are saved. I think the makedumpfile tool can be used to exclude free pages, but I have not tested it. Now, only the i386 architecture is supported. The patch is based on Linux kernel 2.6.23-rc3-mm1, and has been tested on my IBM T42. Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patch and compile. The kexec-tools kjump patch is appended with the mail. The precompiled kexec can be download from: http://linux-mcr700.sourceforge.net/kjump/kexec 3. Download and compile the krestore tool. The source code and precompiled binary can be downloaded from the following URL: source: http://linux-mcr700.sourceforge.net/kjump/krestore.tar.gz binary: http://linux-mcr700.sourceforge.net/kjump/krestore 4. Prepare 3 root partition used by kernel A, kernel B, kernel C, refered as /dev/hda, /dev/hdb, /dev/hdc in following text. This is not strictly necessary, I use this scheme for testing during development. 5. Boot kernel compiled for normal usage (kernel A), the reserved crash kernel memory region must be added to kernel command line as follow: crashkernel=XXM@XXM Where, XX should be replaced by the real memory size and position. I use [EMAIL PROTECTED] in my testing. 6. Load kernel compiled for hibernating usage (kernel B) as a crashdump kernel with kexec, the same kernel as that of 5 can be
RE: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation
One quick question is, can it improve hiberation/wakeup time? Best regards Hu, Fenghua -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Huang, Ying Sent: 2007年8月27日 9:14 To: Eric W. Biederman; Pavel Machek; [EMAIL PROTECTED]; Andrew Morton; Jeremy Maitin-Shepard; Alan Stern Cc: [EMAIL PROTECTED]; Kexec Mailing List; linux-kernel@vger.kernel.org Subject: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation Kexec base hibernation has some potential advantages over uswsusp and TuxOnIce (suspend2). Some most obvious advantages are: 1. The hibernation image size can exceed half of memory size easily. 2. The hibernation image can be written to and read from almost anywhere, such as USB disk, NFS. 3. It is possible to eliminate freezer from kexec based hibernation implementation. 4. Based on kexec/kdump implementation, the kernel code needed is less. This patch set implements a prototype of kexec based hibernation. The kernel functionalities added are as follow: 1. Jumping from kexeced kernel back to original kernel. This is used by hibernation to save/load necessary state in original kernel and jumping back to original kernel after restore the memory of original kernel. 2. Add writing support to /dev/oldmem. This is used by hibernation to restore the memory of original kernel. The hibernation process with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. 4. Save the memory image of kernel A through crash dump (such as cp /proc/vmcore ~). Save the jump buffer pfn. 5. Shutdown or reboot The restore process with the patch set is as follow: 1. Boot a kernel C 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory area used by kernel D must be a subset of memory area used by kernel B. 3. Restore the memory image of kernel A through /dev/oldmem. Restore the jump buffer pfn. 4. Jump from kernel D back to kernel A 5. Continue work under kernel A The following user-space tools are needed to implement hibernation and restore. 1. kexec-tools needs to be patched to support kexec jump. The patch is attached in this mail. The precompiled kexec can be download from: http://linux-mcr700.sourceforge.net/kjump/kexec 2. Memory image saving tool. Currently, the memory image saving is done through: cp /proc/vmcore image file. This will save all memory pages of original kernel including the free pages. Maybe the crash dump tool makedumpfile can be used for this, but it has not been tested. 3. Memory image restore tool. A simplest memory image restoring tool named krestore is implemented. It can be downloaded from following URL: source: http://linux-mcr700.sourceforge.net/kjump/krestore.tar.gz binary: http://linux-mcr700.sourceforge.net/kjump/krestore Known issues: 1. The kernel B run as a crashdump kernel in reserved memory region. This is the biggest constrains of the patch set and planed to be eliminated in the future version. That is, instead of reserving memory region previously, the needed memory region is backupped before kexec and restored after jumping back. 2. Another constrains of the patch set is that the CONFIG_ACPI must be turned off to make kexec jump work. Because ACPI will put devices into low power state, the kexeced kernel can not be booted properly under it. This constrains can be eliminated by separating the suspend method and hibernate method of the devices as proposed earlier in the LKML. 3. The setup of hibernation/restore is fairly complex. I will continue working on simplifying. 4. Memory pages including free pages of kernel A are saved. I think the makedumpfile tool can be used to exclude free pages, but I have not tested it. Now, only the i386 architecture is supported. The patch is based on Linux kernel 2.6.23-rc3-mm1, and has been tested on my IBM T42. Usage: 1. Compile kernel with following options selected: CONFIG_X86_32=y CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image CONFIG_PM=y CONFIG_KEXEC_JUMP=y 2. Download the kexec-tools-testing git tree, apply the kexec-tools kjump patch and compile. The kexec-tools kjump patch is appended with the mail. The precompiled kexec can be download from: http://linux-mcr700.sourceforge.net/kjump/kexec 3. Download and compile the krestore tool. The source code and precompiled binary can be downloaded from the following URL: source: http://linux-mcr700.sourceforge.net/kjump/krestore.tar.gz binary: http://linux-mcr700.sourceforge.net/kjump/krestore 4. Prepare 3 root partition used by kernel A, kernel B, kernel C, refered as /dev/hda, /dev/hdb, /dev/hdc in following text. This is not strictly necessary, I use this scheme
RE: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation
On Mon, 2007-08-27 at 09:28 +0800, Hu, Fenghua wrote: One quick question is, can it improve hiberation/wakeup time? In general, for kexec based hibernation, what increases hibernation/wakeup time: - One extra Linux boot is needed to hibernate and wakeup. What decreases hibernation/wakeup time: - Most hibernation/wakeup work is done in full functional user space program, so it is possible to do some optimization, such as parallel compression. So, I think the kexec based hibernation may be slower than original implementation in general. In this prototype implementation, the hibernation/wakeup time is much longer than original hibernation/wakeup implementation. But it has much to be optimized and I think it can approach the speed of the original implementation after optimization. For example, the hibernation image is an ordinary ELF file, so it can be loaded by bootloader directly. Best Regards, Huang Ying Best regards Hu, Fenghua -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Huang, Ying Sent: 2007年8月27日 9:14 To: Eric W. Biederman; Pavel Machek; [EMAIL PROTECTED]; Andrew Morton; Jeremy Maitin-Shepard; Alan Stern Cc: [EMAIL PROTECTED]; Kexec Mailing List; linux-kernel@vger.kernel.org Subject: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation Kexec base hibernation has some potential advantages over uswsusp and TuxOnIce (suspend2). Some most obvious advantages are: 1. The hibernation image size can exceed half of memory size easily. 2. The hibernation image can be written to and read from almost anywhere, such as USB disk, NFS. 3. It is possible to eliminate freezer from kexec based hibernation implementation. 4. Based on kexec/kdump implementation, the kernel code needed is less. This patch set implements a prototype of kexec based hibernation. The kernel functionalities added are as follow: 1. Jumping from kexeced kernel back to original kernel. This is used by hibernation to save/load necessary state in original kernel and jumping back to original kernel after restore the memory of original kernel. 2. Add writing support to /dev/oldmem. This is used by hibernation to restore the memory of original kernel. The hibernation process with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. 4. Save the memory image of kernel A through crash dump (such as cp /proc/vmcore ‾). Save the jump buffer pfn. 5. Shutdown or reboot The restore process with the patch set is as follow: 1. Boot a kernel C 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory area used by kernel D must be a subset of memory area used by kernel B. 3. Restore the memory image of kernel A through /dev/oldmem. Restore the jump buffer pfn. 4. Jump from kernel D back to kernel A 5. Continue work under kernel A The following user-space tools are needed to implement hibernation and restore. 1. kexec-tools needs to be patched to support kexec jump. The patch is attached in this mail. The precompiled kexec can be download from: http://linux-mcr700.sourceforge.net/kjump/kexec 2. Memory image saving tool. Currently, the memory image saving is done through: cp /proc/vmcore image file. This will save all memory pages of original kernel including the free pages. Maybe the crash dump tool makedumpfile can be used for this, but it has not been tested. 3. Memory image restore tool. A simplest memory image restoring tool named krestore is implemented. It can be downloaded from following URL: source: http://linux-mcr700.sourceforge.net/kjump/krestore.tar.gz binary: http://linux-mcr700.sourceforge.net/kjump/krestore Known issues: 1. The kernel B run as a crashdump kernel in reserved memory region. This is the biggest constrains of the patch set and planed to be eliminated in the future version. That is, instead of reserving memory region previously, the needed memory region is backupped before kexec and restored after jumping back. 2. Another constrains of the patch set is that the CONFIG_ACPI must be turned off to make kexec jump work. Because ACPI will put devices into low power state, the kexeced kernel can not be booted properly under it. This constrains can be eliminated by separating the suspend method and hibernate method of the devices as proposed earlier in the LKML. 3. The setup of hibernation/restore is fairly complex. I will continue working on simplifying. 4. Memory pages including free pages of kernel A are saved. I think the makedumpfile tool can be used to exclude free pages, but I have not tested it. Now, only the i386 architecture is supported. The patch is based on Linux kernel 2.6.23-rc3-mm1, and has been tested on my IBM T42
Re: [RFC][PATCH 0/2 -mm] kexec based hibernation
On Mon, Aug 27, 2007 at 09:14:05AM +0800, Huang, Ying wrote: Kexec base hibernation has some potential advantages over uswsusp and TuxOnIce (suspend2). Some most obvious advantages are: 1. The hibernation image size can exceed half of memory size easily. 2. The hibernation image can be written to and read from almost anywhere, such as USB disk, NFS. 3. It is possible to eliminate freezer from kexec based hibernation implementation. 4. Based on kexec/kdump implementation, the kernel code needed is less. This patch set implements a prototype of kexec based hibernation. The kernel functionalities added are as follow: 1. Jumping from kexeced kernel back to original kernel. This is used by hibernation to save/load necessary state in original kernel and jumping back to original kernel after restore the memory of original kernel. 2. Add writing support to /dev/oldmem. This is used by hibernation to restore the memory of original kernel. The hibernation process with the patch set is as follow: 1. Boot a kernel A 2. Work under kernel A 3. Kexec another kernel B (crash dump enabled) in kernel A. 4. Save the memory image of kernel A through crash dump (such as cp /proc/vmcore ~). Save the jump buffer pfn. 5. Shutdown or reboot The restore process with the patch set is as follow: 1. Boot a kernel C 2. Kexec another kernel D (crash dump enabled) in kernel C. The memory area used by kernel D must be a subset of memory area used by kernel B. If one compiles the kernel C to boot from reserved memory area (subset of memory area used by kernel B), then I can skip the step of kexecing from C to D? (COFIG_PHYSICAL_START) Alternatively, can we give hint to kernel C to run from a specified address at run time with the help of command line parameters. What I mean boot-loader can load the kernel at any address, but kernel will move itself to run from a different location depending on command line parameter. For example, let say kernel_run_addr = 0x100. This parameter will tell the kernel to move itself to 16MB address and run from there. I think it can be made to work with little work in existing setup of relocatable kernel. Kernel run address can be put by some user space script which will save the hibernated image of original kernel. So after saving the /proc/vmcore, script can modify the boot loader config file to append the right command line to the kernel (kernel_run_addr). After hibernation, user will shutdown/reboot. Next time the kernel boots it will load at 16MB addr (because of kernel_run_addr) and then it can restore the previously saved image. We shall have to get rid of (kernel_run_addr) parameter from command line while resuming. One can restore the image (krestore) and then edit the boot loader config file to get rid of command line param, kernel_run_addr. In this scheme, with the help of relocatable kernel, we can use a single kernel for everything. (A, B, C, D). We will also avoid additional kexec from kernel C to kernel D. I think in the long run we shall have to work out so that a user does not have to maintain multiple kernels. Does this make sense? Thanks Vivek - 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/
