Re: [PATCH] Remove process freezer from suspend to RAM pathway

Rafael J. Wysocki
2007-07-03T12:49:40Z

On Tuesday, 3 July 2007 09:19, Benjamin Herrenschmidt wrote:
> On Tue, 2007-07-03 at 16:08 +1000, Nigel Cunningham wrote:
> >
> > > So I think Matthew is totally right. In fact, the presence of the
> > > freezer is the main reason why Paulus so far NACKed Johannes attempts at
> > > merging the PPC PM code with the generic code in kernel/power.c
> > >
> > > We've been doing fine without it so far and intend to continue to do so.
> >
> > Fuse depends on !PPC?
>
> No, that's not what I'm saying. I'm saying we've been doing STR without
> the freezer and that's the way to go imho.
>
> > > As for suspend-to-disk, I refer you to the discussions we had in the
> > > past with Linus, where he explains I think quite clearly how wrong the
> > > current implementation of STR is :-)
> >
> > I assume you mean STD.
>
> Oops, yeah, sorry.
>
> > The problem there is that Linus doesn't care about STD.
> > If he did, I dare say he'd think through the issues more thoroughly than he
> > apparently has.
>
> Heh, that might be the case :-)
>
> > > Thing is, if you're going to do snapshots, you should probably not sync
> > > after you have "frozen" anyway.
> >
> > Fully agree. But how do you stop things syncing while you're writing the image
> > if you don't have a freezer or equivalent? (scheduler based, kexec.. they're
> > all workarounds for this issue).
>
> Well, I was saying that in the context of the -current- snapshotting
> mechanism which is based on the freezer, then you should not
> sys_sync().
>
> Some random user or kernel thread doing a sync is not a problem. It will
> stop in the middle of sync and resume on wakeup.
>
> The problem is currently because STD -itself- attempts to sync after it
> has frozen things.

To be precise, it tries to sync after it has frozen the user land.

> I think that should be changed. If you want to sync for whatever reason,
> (mostly save RAM ?) do it before the freeze. That means you may get new
> dirty data in memory that isn't written out by the sync before you
> freeze, but that's allright, that data will be in the suspend image
> anyway. If you fail to wakeup, that's akin to a normal crash, the user
> will only lose the last data written at the time of the suspend and
> journaling fs'es should take care of fs metadata integrity.
>
> So to summarize, the plan that makes things work with fuse is:
>
> - For STR, don't do the freezer thing.

In the long run, I agree.

Still, can you please read this post from Alan Stern:

https://lists.linux-foundation.org/pipermail/linux-pm/2007-June/012847.html

? I don't think I'm able to repeat the arguments given in there in a
convincing way.

> - For STD, don't sys_sync() after you froze

Yeah, I think we can move the syncing before the freezing, so to speak.

And it need not be called from within the freezer, BTW.

> There might be -other- issues, but that should get you through some of
> them at least. Of course, you'll be in trouble if you try to do things
> like STD-to-a-file which sits on a fuse FS but there's a limit to
> insanity :-)

Yes. :-)

Ggreetings,
Rafael

--
"Premature optimization is the root of all evil." - Donald Knuth