Re: [RFC][PATCH -mm] Freezer: Handle uninterruptible tasks

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Saturday, 7 July 2007 01:00, Rafael J. Wysocki wrote:
> On Saturday, 7 July 2007 00:38, Oliver Neukum wrote:
> > Am Freitag, 6. Juli 2007 schrieb Oleg Nesterov:
> > > Rafael J. Wysocki wrote:
> > > >
> > > > This patch makes the freezer skip uninterruptible user space tasks (ie. such
> > > > that have an mm of their own) when counting the tasks to be frozen.  As a
> > > > result, these tasks have the TIF_FREEZE and TIF_SIGPENDING flags set, but the
> > > > freezer doesn't wait for them to enter the refrigerator.  Nevertheless, they
> > > > will enter the refrigerator as soon as they change their state.
> > > 
> > > A small correction: they will enter the refrigerator on return to user-space.
> > 
> > That is too late. We would need them to go to sleep as soon as they are
> > woken up. This does not matter if they are in uninterruptible sleep due to
> > fuse deadlocking, as they won't be woken up, but it kills the other cases.
> 
> I'm sorry I can't write anything more about that right now, I'll write more
> tomorrow.
> 
> For now, I can only say that I have reasons to believe that the other cases
> are not likely to "leak" through the freezer.

OK, sorry for the delay.

The first reason is that a similar approach had been used by suspend2 for
quite some time without any visible adverse effects.  Of course this is not
a proof, but it means that the undesirable conditions are not easy to trigger
(if at all possible).

Next, if an uninterruptible task A waits on a mutex (or semaphore), then there
is a task B that holds it.  This task may be a kernel thread or a user space
process.  In the latter case it may also be uninterruptible, but then we can 
consider that task instead of A, so assume that B is interruptible.  In that
case, however, B is also freezable, but before it's frozen, it must release the
mutex.  In that case A will become freezable before B is frozen and the freezer
will have a chance to start to count A.  Thus, in that case A won't "leak"
through the freezer in the uninterruptible state.

Now, if B is a kernel thread, it might hold the mutex longer than the freezer
is running, but it has to have a reason for that.  Namely, I think that in
practice this can only happen if the resource protected by the lock is
unavailable.  In that case, task A may potentially cause problems to happen
if the resource becomes available during the suspend or resume at exactly
the right moment (eg. when .suspend() that task A may interfere with is being
executed).  IMO, this is unlikely.

I think that this also applies to the situation in which an uninterruptible task
waits for an event to occur (like a completion).  Namely, if the event waited
for by the task doesn't occur relatively quickly (like within a few scheduling
cycles), then it's likely not to occur throughout the entire suspend/resume
cycle.

This doesn't mean that no problems will happen no matter what, but at least
they are much less likely to happend than in the case when we remove the
freezer entirely without doing anything about the drivers before.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/