[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18060.16064.519060.755991@cargo.ozlabs.ibm.com>
Date: Thu, 5 Jul 2007 10:43:44 +1000
From: Paul Mackerras <paulus@...ba.org>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: stern@...land.harvard.edu, oliver@...kum.org, rjw@...k.pl,
mjg59@...f.ucam.org, linux-pm@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM
pathway
Miklos Szeredi writes:
> OK, let me summarize the situation as I see it now: there are two
> camps, the pro-freezers and the anti-freezers.
>
> Pro-freezers say:
>
> - don't remove the freezer, otherwise we'll have to deal with
> numerous problems in drivers
>
> Anti-freezers say:
>
> - let's remove the freezer, which causes numerous problems
>
> Alan summerized the pro-freezer arguments well I think. What are the
> anti-freezer arguments then?
1. The freezer cannot be guaranteed deadlock-free without constructing
a dependency graph between tasks (both user and kernel), which is
virtually impossible since the dependencies are not externally
observable.
2. As a consequence of (1), we try to make a crude approximation of
the graph by saying "only kernel threads that want to be frozen
will be frozen" or some other similar statement.
3. However, (2) means that we can no longer guarantee that drivers
will not get any I/O requests after their suspend method has been
called, and therefore the freezer fails in its main objective.
4. We have an existence proof that reliable suspend can be achieved
without the freezer.
To summarize, the argument is that the freezer is deadlock-prone and
ineffective.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists