On Wed, 2008-03-12 at 08:59 +1100, Nigel Cunningham wrote:
quoted text
> Hi all.
> 
> I hope kexec turns out to be a good, usable solution. Unfortunately,
> however, I still have some areas where I'm not convinced that kexec is
> going to work or work well:
> 
> 1. Reliability.
> 
> It's being sold as a replacement for freezing processes, yet AFAICS it's
> still going to require the freezer in order to be reliable. In the
> normal case, there isn't much of an issue with freeing memory or
> allocating swap, and so these steps can be expected to progress without
> pain. Imagine, however, the situation where another process or processes
> are trying to allocate large amounts of memory at the same time, or the
> system is swapping heavily. Although such situations will not be common,
> they are entirely conceivable, and any implementation ought to be able
> to handle such a situation efficiently. If the freezer is removed, any
> hibernation implementation - not just kexec - is going to have a much
> harder job of being reliable in all circumstances. AFAICS, the only way
> a kexec based solution is going to be able to get around this will be to
> not have to allocate memory, but that will require permanent allocation
> of memory for the kexec kernel and it's work area as well as the
> permanent, exclusive allocation of storage for the kexec hibernation
> implementation that's currently in place (making the LCA complaint about
> not being able to hibernate to swap on NTFS on fuse equally relevant).

As Eric said kexec need only to allocate memory during loading, not
executing.
 
quoted text
> While this might be feasible on machines with larger amounts of memory
> (you might validly be able to argue that a user won't miss 10MB of RAM),
> it does make hibernation less viable or unviable for systems with less
> memory (embedded!). It also means that there are 10MB of RAM (or
> whatever amount) that the user has paid good money for, but which are
> probably only used for 30s at a time a couple of times a day.
> 
> Any attempt to start to use storage available to the hibernating kernel
> is also going to have these race issues.

I think this can be avoid such as preallocate some hard disk space (such
as a dedicate hibernating file, the block list are loaded by
kexec-tools).

quoted text
> 2. Lack of ACPI support.
> 
> At the moment, noone is going to want to use kexec based hibernation if
> they have an ACPI system. This needs to be addressed before it can be
> considered a serious contender.

ACPI is the biggest challenge for kexec based hibernation. I will try to
deal with it. But for most people, ACPI is not a big issue. This is
hibernation, not suspend to RAM.

quoted text
> 3. Usability.
> 
> Right now, kexec based hibernation looks quite complicated to configure,
> and the user is apparently going to have to remember to boot a different
> kernel or at least a different bootloader entry in order to resume. Not

No, the newest implementation need not to boot a different kernel or
different bootloader entry. You just use one bootloader entry, it will
resume if there's an image, booting normally if there's not. You can
look at the newest hibernation example description.

And the new method can even be used to load hibernation image of uswsusp
too.

quoted text
> a plus. It would be good if you could find a way to use one bootloader
> entry, resuming if there's an image, booting normally if there's not.

Best Regards,
Huang Ying

--
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/