Technology news and Jobs 
linux.conf.au Debian made this developer unhappy
linux.conf.au Debian made this developer unhappy | Debian made this developer unhappy |
|
| by Sam Varghese | |
| Friday, 08 February 2008 | |
|
Page 5 of 5 Can you tell me a little bit about the talk you gave at the conference? Featured Whitepaper
5 Best Practices for Smartphone Support
I was discussing the suspend to disk implementation in Linux - that part of the kernel code that is responsible for allowing you to save your system's state to disk and then restore it at a later time. And the method of doing it would be to allow you to shut your computer down so that it's consuming no power, but to come back to the same state with the same applications. Similar to shutting the cover of your laptop... Yes, there's suspend to RAM which means the computer is still consuming power. Suspend to disk is slower but it means the hardware is not working and therefore it is consuming no power and you can leave your computer in that state for as long as you like and resume it. The existing implementation of suspend to disk in Linux, it's difficult to make it work correctly. The main problem is what's called the freezer, which is responsible for stopping running processes so that the state gets copied to disk without changing. Unfortunately due to the way this is designed, it is impossible to reliably freeze some processes. because they may be doing something that means that they won't go through the part of the kernel which is responsible for freezing. For the reasons I've just outlined, it is not likely that we can ever get the freezer to work reliably. What is the freezer? Is it part of the kernel? It's a core part of the kernel process scheduling code. Are you looking towards a solution for that? I'm looking towards a solution for that and it seems like the most likely solution is to use a process called kexec which is a part of the kernel code that allows you to replace the kernel. That means you can switch kernels without disturbing the state of the original kernel. And then jump into the new kernel, and the new kernel can save the state of the old kernel. There's a kernel you're running which is running all your processes; kexec allows you to load another kernel without rebooting the computer and then you execute that kernel. So you would be running a second instance of the same kernel? It could be the same kernel or a different kernel, it really doesn't matter. That kernel is able to access all the memory of the original kernel. So it can copy that to disk without having to interfere with its state. The problem is, when you're saving to disk you're executing code which is changing the contents of memory. And that's a problem if you're going to save that memory to disk. The advantage of kexec is that it's only altering the memory of the new kernel while saving the old kernel. Are you planning to start work on this or having you already started work? I have been looking at it. There's actually a guy working for Intel in China who has been working on this for the past couple of months. I'm thinking of getting involved so that we can move towards using kexec in Linux. |
Tags
| < Next story in category | Previous story in the category > |
|---|
