Date:	Thu, 12 Jul 2007 03:10:54 -0700 (PDT)
From:	david@...g.hm
To:	"Huang, Ying" <ying.huang@...el.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Machek <pavel@....cz>, nigel@...el.suspend2.net,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jeremy Maitin-Shepard <jbms@....edu>,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org
Subject: Re: [PATCH 0/2] Kexec jump: The first step to kexec	base	hibernation

On Thu, 12 Jul 2007, Huang, Ying wrote:

> On Thu, 2007-07-12 at 00:03 -0700, david@...g.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)

>>> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists