Re: [Ksummit-discuss] [TECH TOPIC] giving freezer well-defined semantics

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Wednesday, July 08, 2015 10:16:39 AM Jiri Kosina wrote:
> On Wed, 8 Jul 2015, Rafael J. Wysocki wrote:
> 
> > OK, it is necessary to ensure that the contents of the image will be 
> > consistent with the state of filesystems on the storage media, so 
> > everything that may change that state should be "frozen" before the 
> > image is created, but "frozen" in terms of "no persistent state changes 
> > from now on" rather than in terms of "no forward progress from now on".
> 
> Yeah. So again, why do we even have freezer for so many kernel threads at 
> all? :)

Well, one reason may be that we've never grown a decent mechanism for freezing
filesystems (as in "no persistent state changes from now on") and people try to
make up for that by stopping things if they can (but in the kernel space that's
inherently racy).

There also are places where it has been forever and no one is sure what happens
after it's been dropped from there.

And there are places where it is used to provide specific guaranees (like in
the runtime PM framework), but might be replaced with a different mechanism.

Essentially, as I said above, the freezer is only really useful for things
requiring the "no forward progress from now on" rule.  There are things like
that in the kernel too, but I bet there are not too many of them.

Thanks,
Rafael