Messages in this thread | | | Date | Thu, 12 Jul 2007 12:03:58 -0700 (PDT) | From | david@lang ... | Subject | Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation |
| |
On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
> On Thursday, 12 July 2007 12:10, david@lang.hm wrote: >> On Thu, 12 Jul 2007, Huang, Ying wrote: >> >>> On Thu, 2007-07-12 at 00:03 -0700, david@lang.hm wrote: >>>>> >>>>> The kexec jump is the first step, maybe the simplest step. There are >>>>> many other issues to be resolved, at least the following ones. >>>>> >>>>> 1. Separate device suspend from device hibernate. >>>> >>> >>> Maybe my usage of terminology has some problem. But, the "device >>> hibernate" here means put device into quiescent state and save the >>> device state, but do not put device into low power state. >> >> is there really enough savings (in time or otherwise) to make it worth >> splitting this into two steps? for suspend-to-ram we definantly will need >> to option to go all the way to a low power state, there's significant >> extra complexity if you also have a state between normal operation and >> this low power state. >> >> it may be worth doing if the low-power state is expensive (in time or >> effort) to get to or from and the lesser state allows the computer overall >> to save power (like the different cpu C states) >> >> but I suspect that the number of drivers where this is worth doing is >> relativly small, and it may be a better approach to start off with just >> putting everything into the low-power state until some drive shows up that >> makes it worth adding the intermediate state to the system (and drivers >> wouldn't have to change, if they only support one suspend state it's the >> low-power one, if they support more then higher layers choose which ones >> to move to) > > We've discussed that a lot on linux-pm and the conclusion is that devices > should not be put into low power states before creating the hibernation > image, because that leads to problems during the restore.
too bad, I was thinking that a driver in a low-power state could be initialized normally and we could avoid having different quiesce and low-power states
> In turn, during the restore, when the image has been loaded and the "old" > kernel gets the control, it should reprobe devices and initialize them from > scratch rather than doing something like "resume devices after suspend > to RAM".
this makes sense.
>>>>> 6. Reduce the boot-up time of kexec kernel. Maybe the kexec kernel can >>>>> be hibernate/resume by the normal kernel too. This way, a real >>>>> kexec/boot-up is only needed for the first time. >>>> >>>> the hibernate kernel shouldn't need a lot of the features of the standard >>>> kerneel (does it really need sound for example), and if tailored even >>>> tighter could be configured to only have the drivers actually used for the >>>> save and restore, makeing a _very_ minimal kernel (no USB, no network, >>>> only simple video drivers, etc) greatly speeding up the boot >>> >>> There is no need for two kernel. Most drivers and optional features are >>> compiled as modules, as that of most desktop distributions. So just >>> "insmod" needed modules only in hibernate kernel is sufficient. >> >> actually, I think that while you may be able to get away with only one >> kernel, you are probably better off with two. on the hibernate kernel you >> can choose many 'embedded' options that don't make sense for the normal >> kernel (no high mem, no SMP support, no SELinux, no network routing, not >> netfilter, use SLOB not SLAB/SLUB, etc). also keep in mind that each >> module that you load wastes apartial page of memory. >> >> remember people run complete linux systems in 8M of ram, a syspend system >> for a simple 'write the ram image to partition X on this IDE drive' should >> be aiming at 2-4M of memory. >> >> more complex setups may want more space, but let the distros bloat things >> up, design and demo an optimized system :-) > > So if a user wants to install a kernel.org kernel on his system, (s)he'll have > to compile and install two kernels with different options.
for now allow this option as it's the simplest to implement (it takes extra work to re-use the kernel)
also, the objections to the auto-config kernel requests have mostly been how it's impossible for the auto-config to get enough things right. in the case of a hibernate kernel I think it's such a minimal config that it should be possible to have an auto-config script that you tell 'I plan to suspend to partition X, give me a minimal kernel that can access ram, that partition, and the framebuffer (for status output)' and have it produce a tiny kernel with only thta support
> That doesn't sound good to me. :-)
on the other hand, booting a standard distro kernel that does hotplug detection for everything it can find on the system is far from optimal as well.
David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |