On Thu, 12 Jul 2007, Huang, Ying wrote:
On Thu, 2007-07-12 at 00:03 -0700, [email protected] 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)
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 :-)
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
