Re: hibernation/snapshot design [was Re: [PATCH] Remove process freezer from suspend to RAM pathway]

[Pavel Machek]

On Sun 2007-07-08 16:20:46, david@xxxxxxx wrote:
> On Mon, 9 Jul 2007, Pavel Machek wrote:
> 
> >>>>>Actaully, I'm perfectly fine with that, as long as each task blocked by
> >>>>>the
> >>>>>driver due to suspend has PF_FROZEN (or something similar) set.  Then, 
> >>>>>at
> >>>>>least theoretically, we'll be able to drop the freezer from the suspend
> >>>>>code
> >>>>>path and move it after device_suspend() (or the hibernation-specific
> >>>>>equivalent) for hibernation (in that case there shouldn't be a problem
> >>>>>with
> >>>>>any task waiting on I/O while the freezer is running ;-)).
> >>>>
> >>>>I don't see the need for a freezer for snapshot but that's a different
> >>>>issue. (stop_machine looks good enough to me).
> >>>
> >>>Freezer is not needed for snapshot -- it is needed so that we can
> >>>write out the snapshot to disk without the need for special
> >>>drivers/block/simple-ide-for-suspend.c. (We are doing snapshot, then
> >>>write to disk from userland code in uswsusp).
> >>
> >>instead of trying to freeze most of the system, could you do something
> >>like start a virtual machine sandbox to write the data out, and not let
> >>any userspace other then the sandbox operate?
> >>
> >>you would need to throw away disk buffers so that you don't mix current
> >>pending I/O with I/O from the sandbox, and this would be a visable change
> >>for how suspend is setup, but wouldn't this work?
> >
> >It feels kind of expensive, but yes, we could use another kernel for
> >doing the dump. Kdump people are using that. We could use hypervisor
> >for doing the dump. Xen people are doing that. (But I do not think any
> >of those solutions is suitable for "lets hibernate my notebook" case).
> 
> expensive and reliable beats efficiant and unrelaible.
> 
> why do you say that neither would work for the "lets hibernate my 
> notebook" case?

Both would work. One would eat 8-64MB of your RAM, permanently; second
would eat 5-15% of your cpu, permanently. Not very suitable.

Who says current solution is unreliable?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/