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

Nigel Cunningham
2007-07-03T06:08:23Z

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

Hi.

On Tuesday 03 July 2007 15:48:26 Benjamin Herrenschmidt wrote:
>
> > Note, though, that this won't help at all when people use
the "suspend-to-ram
> > instead of powering down after writing a hibernation image" feature in
> > (uswsusp | tuxonice). Fuse is just a broken idea in the first place, but
> > given that it exists, we still need to find the underlying cause.
>
> No, Fuse is not a broken idea in the first place. It's the freezer that
> is a totally broken idea. It has proven many times to be racy by design
> and cannot be made right. Ther usermode helper mess is just part of
> that, fuse is another example, etc etc ...

To some extent, I agree. I think the ideal solution would be to simply not
schedule processes that are supposed to be frozen. But who wants to play with
scheduler code? Not me!

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

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

> 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).

Regards,

Nigel
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]