Cc: Linus Torvalds <torvalds@...>, Rafael J. Wysocki <rjw@...>, Jeff Chua <jeff.chua.linux@...>, lkml <linux-kernel@...>, Dave Airlie <airlied@...>, <linux-acpi@...>, suspend-devel List <suspend-devel@...>, Greg KH <gregkh@...>
No. AFAICS, kexec is going to be more complex and ugly in many ways.
To summarise, a kexec based hibernation is going to need the following
additional requirements to just replace what we already have:
- get the original kernel to allocate storage while racing against the
rest of the system (currently allocation is done post-atomic copy &
post-freezing - no racing). This makes it potentially slower, too;
- get the original kernel to transfer the information about what swap
was allocated to the kexec'd kernel, probably together with a lot of
other information (which pages are nosave etc).
- get the original kernel to keep memory free for the kexec'd kernel
which would otherwise be usable. Not a biggy on desktops or laptops, but
think about embedded.
- people keep talking about hibernating to an ext3 fs mounted on fuse as
a limitation of the freezer. To do that with kexec, you're still going
to have to bmap the ext3 fs and pass the block list (in which case we
can also do it without kexec) or umount all the ext3/fuse part and
remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it?
I also wonder about how much of a pain it's going to be setting up
userspace for this kexec'd kernel. Will you need a separate partition
just for it? If not, will the userspace be loaded into memory all the
time (more memory wasted for normal use), or loaded from ordinary
partitions at kexec time (how to do safely? - more info to transfer
between kernels?).
I'd love it if kexec really was the panacea to the freezer issues, but
problems like these make me think it isn't a viable solution.
Nigel
--
