Re: [PATCH 2/2] Fix console handling during suspend/resume

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2006-06-21 at 08:08 -0700, Linus Torvalds wrote:

> > 4-driver thaw, subsystems stay frozen (that is VM, filesystems,
> > userland)
> 
> Yes and no. We might actually want to thaw some subsystems too. 
> 
> Obviously, there's no reason to thaw user programs (even if you could 
> wake them up, they couldn't be allowed to make any forward progress that 
> is "visible"), but once you have snapshotted things, you might actually be 
> better off allowing a fair amount of "normal" operations.

As long as you don't go anywhere near persistant storage like
filesystems... Might be worth having a global ro remount as part of
preparing subsystems....

> For example, you might decide that you want to actually _kill_ all user 
> processes at that point, and allow kernel processes that you wanted 
> quiescent for snapshotting to thaw. Once you have built the snapshot 
> image, many of the reasons to freeze are gone - not just for drivers.

Ok.

> At that point, the only thing you want to make sure of is that nobody 
> writes to swap any more, and doesn't write to the filesystem (or network, 
> for that matter).
> 
> > 5-shutdown or driver suspend S4
> 
> Not yet. 
> 
>  5 - write snapshot to disk
> 
> Because ytou need to do that after the thaw, of course.

Yes, sure, that one was so obvious that I forgot about it :)

> And only _then_ do you actually shutdown or do S4.

Yup.

> > The only little possible issue there is that the subsystems being still
> > stopped, some drivers may need to have a hard time doing 5 if they need
> > to send requests to their own hardware for things like hard disk
> > spindown, and they happen to use the block layer request queue for that
> > (pumping device specific requests into it).
> 
> I'd wake up all kernel daemons after snapshotting. There's no reason not 
> to, really (kswapd might be a special case, but quite frankly, I think 
> we're better off "turning off swap" than necessarily turning off kswapd 
> itself - ie again, the appropriate level to make sure swap doesn't get 
> dirtied afterwards is likely _higher_ up than the level that actually 
> makes the IO itself happen).

Beware with things like knfsd trying to hit your filesystems too ...

Ben.