Re: Hibernation Redesign

[Jeremy Maitin-Shepard <jbms@cmu.edu>]

Nick Piggin <nickpiggin@yahoo.com.au> writes:

> Jeremy Maitin-Shepard wrote:
>> Al Boldi <a1426z@gawab.com> writes:
>> 
>> 
>>> Pavel Machek wrote:
>>> 
>>>> We are stuck with refrigerator for now, and at least for hibernation,
>>>> I don't see any feasible alternative.
>> 
>> 
>>> Feasible alternative?
>> 
>> 
>> I posted such an alternative to the list a short time ago: hibenrating
>> from a *new* kernel space/user space that is created by loading a new
>> kernel in a manner similar to what is done for kexec crashdumps.  Unlike
>> kexec crashdumps, however, it would not require reserving any memory at
>> boot, because the necessary memory (maybe 16MB or 64MB) can be freed
>> just before hibernating, and device drivers can be properly stopped so
>> that DMAs don't stomp over certain memory.

> This is the Morton method, isn't it? :) I remember it sounding like a
> very good idea when he brought it up, but I can't remember the details
> of why it was rejected or what the problems were.

Perhaps he did bring it up before I did.  Please forward me a link to
the thread or other reference if you can find it, as I'd be interested
in reading it.


>> This approach eliminates the need for the freezer, as it would make
>> hibernate look a lot a bit like suspend to ram from the perspective of
>> the "old" kernel (the kernel being hibernated), as the hibernate
>> operation itself would be completely atomic from the perspective of the
>> "old" kernel.  That is not to say, of course, that any code paths would
>> actually be shared, or that the drivers would do the same things
>> (because they probably would not).

> Well it basically is suspend to RAM with the additional step that a
> new kernel gets booted and writes out the data from RAM to disk then
> shuts down.

There is the key difference, though, that the drivers should do rather
different things.  In particular, rather than place the hardware in a
low-power mode, it should place it in some state such that the new
kernel being loaded can handle it.

> I suspect that freeing memory on the fly for the new kernel
> would be non-trivial (but possible), however simply having a reserve
> RAM region for the new kernel would be fine for a first step.

Freeing memory on the fly should be extremely easy for the kernel (this
is precisely what it does when it needs to satisfy an allocation).  Note
that the memory allocated need not be contiguous.

-- 
Jeremy Maitin-Shepard