Is the suspend be the job of OS instead of firmware?
I wonder if kexec or kdump could load another kernel to dump previous kernel to disk partition or file.
Also wonder if you have one kernel to use kexec reload one dumped image?
YH
On Mon, Dec 11, 2006 at 10:59:26AM -0800, Lu, Yinghai wrote:
Is the suspend be the job of OS instead of firmware?
That's an interesting question. Proprietary BIOSes used to do suspend to disk - I had a laptop 7 years ago that did it (HP Omnibook XE2). Every laptop I've owned since then does not have a suspend feature.
Would having the BIOS do suspend require a BIOS callback? What was described in this thread made it sound like a callback is necessary.
Thanks, Ward.
Ward Vandewege ward@gnu.org writes:
On Mon, Dec 11, 2006 at 10:59:26AM -0800, Lu, Yinghai wrote:
Is the suspend be the job of OS instead of firmware?
That's an interesting question. Proprietary BIOSes used to do suspend to disk
- I had a laptop 7 years ago that did it (HP Omnibook XE2). Every laptop I've
owned since then does not have a suspend feature.
Would having the BIOS do suspend require a BIOS callback? What was described in this thread made it sound like a callback is necessary.
Suspend to RAM currently appears to be something that the OS cannot do alone. At least because cpu wakeup has to go through the BIOS.
Beyond that I think you are likely to get a lot more users and a lot more debugging and testing if you put the work in the OS.
Eric
* Eric W. Biederman ebiederm@xmission.com [061211 20:48]:
Beyond that I think you are likely to get a lot more users and a lot more debugging and testing if you put the work in the OS.
One drawback with Linux suspend is both suspend and recover speed. Or the lack thereof. I have not seen a laptop in years where Linux suspend would have a noticable gain over a reboot+shutdown cycle, if there was a gain at all.
On 12/11/06, Eric W. Biederman ebiederm@xmission.com wrote:
Suspend to RAM currently appears to be something that the OS cannot do alone. At least because cpu wakeup has to go through the BIOS.
Beyond that I think you are likely to get a lot more users and a lot more debugging and testing if you put the work in the OS.
we're working on a mostly OS-based approach for OLPC; stay tuned. The handshake with BIOS should be minimal, and require 0 callbacks.
ron
Well, I am very glad to see all the input on this idea. Lets see if I can add some info and sort what we have.
Current speeds. My current system takes about 3 seconds for Linuxbios, then 2 more for kernel, to the suspend2 code, then 7~12sec depending on how much compression I am using on the suspend2 image. So a total boot time of about 15 seconds. Up and playing music, with full X. A normal boot is 33 sec, to get to a full X + music playing. I want sub 10. Dont care about suspending time, just resume. All this is suspend to disk. I need to be able to power the system off of N time.
Could we make suspend be a hybrid process? Taking both firmware and the OS?
No BIOS call backs, I think we can get away with suspending from the OS, and setting a cmos flag for linuxbios to catch on the way up. This would allow us to just restore the "needed" memory, instead of hibernation mess of windows. So place this such code in filo and boot from swap. (Thanks Guido) Things I dont know. Does Suspend2 replace the kernel? Is it a true full image of RAM? Could we use a version of the suspend2 code for resuming only? Could we use ACPI in order to deal with a call back issue? Make this a power call?
Suspend times VS RAM. In the Suspend2 configs, you can tell it to keep the image size down, and it will place most of the ram in swap before making the image. Thus cutting the boot time way down. Even in the case of larger systems with GB+ of ram. Some idea -Adam
ron minnich wrote:
On 12/11/06, Eric W. Biederman ebiederm@xmission.com wrote:
Suspend to RAM currently appears to be something that the OS cannot do alone. At least because cpu wakeup has to go through the BIOS.
Beyond that I think you are likely to get a lot more users and a lot more debugging and testing if you put the work in the OS.
we're working on a mostly OS-based approach for OLPC; stay tuned. The handshake with BIOS should be minimal, and require 0 callbacks.
ron
* Adam Talbot talbotx@comcast.net [061211 23:39]:
My current system takes about 3 seconds for Linuxbios, then 2 more for kernel, to the suspend2 code, then 7~12sec depending on how much compression I am using on the suspend2 image.
Just a thought, the firmware level IDE driver is usually not using DMA or any advanced reading methods, and as such a lot slower than the according Linux driver. You might have a hard time keeping the 2s the kernel needs.
So a total boot time of about 15 seconds. Up and playing music, with full X. A normal boot is 33 sec, to get to a full X + music playing. I want sub 10.
Your calculation goes with 3+2+10s - Instead of tuning the 3s or 2s, you might instead start improving on the biggest piece of the cake: the 10s.
I would assume the 2s kernel do some initialization that are expected to happen for the suspend code to work. So even if you manage to win 2s by not booting a kernel, you might have quite some other things to "fix".
S.
Ouch... well that just shot me down in flames. But, VERY good point. Stefan Reinauer wrote:
- Adam Talbot talbotx@comcast.net [061211 23:39]:
My current system takes about 3 seconds for Linuxbios, then 2 more for kernel, to the suspend2 code, then 7~12sec depending on how much compression I am using on the suspend2 image.
Just a thought, the firmware level IDE driver is usually not using DMA or any advanced reading methods, and as such a lot slower than the according Linux driver. You might have a hard time keeping the 2s the kernel needs.
So a total boot time of about 15 seconds. Up and playing music, with full X. A normal boot is 33 sec, to get to a full X + music playing. I want sub 10.
Your calculation goes with 3+2+10s - Instead of tuning the 3s or 2s, you might instead start improving on the biggest piece of the cake: the 10s.
I would assume the 2s kernel do some initialization that are expected to happen for the suspend code to work. So even if you manage to win 2s by not booting a kernel, you might have quite some other things to "fix".
S.
* Lu, Yinghai yinghai.lu@amd.com [061211 19:59]:
Is the suspend be the job of OS instead of firmware?
LinuxBIOS' effort has indeed been the other way around: Move everything into the OS that is not necessarily a task of the firmware.
Since we have this no-callback paradigm in the LLFW we should probably stick with that.
I wonder if kexec or kdump could load another kernel to dump previous kernel to disk partition or file.
Why would you want to load another kernel first? Can you return from a kexec call and have the original kernel dump the virtual environment of the freshly loaded one?
S.
Stefan Reinauer stepan@coresystems.de writes:
- Lu, Yinghai yinghai.lu@amd.com [061211 19:59]:
Is the suspend be the job of OS instead of firmware?
LinuxBIOS' effort has indeed been the other way around: Move everything into the OS that is not necessarily a task of the firmware.
Since we have this no-callback paradigm in the LLFW we should probably stick with that.
I wonder if kexec or kdump could load another kernel to dump previous kernel to disk partition or file.
Why would you want to load another kernel first? Can you return from a kexec call and have the original kernel dump the virtual environment of the freshly loaded one?
Nope kexec has no provision for returning.
There is some small argument that standing outside the kernel might make the problem easier, but I don't think that helps much.
Eric
-
Adam Talbot -
ebiederm＠xmission.com -
Lu, Yinghai -
ron minnich -
Stefan Reinauer -
Ward Vandewege