On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:

quoted text
> 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

quoted text
> 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.

quoted text
>>>>> 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

quoted text
> 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
-
unsubscribe notice
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/