Re: [ 15/23] [Suspend2] Helper for counting uninterruptible threads of a type.

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

Hi,

On Monday 30 January 2006 23:25, Pavel Machek wrote:
> On Po 30-01-06 23:18:28, Rafael J. Wysocki wrote:
> > On Thursday 26 January 2006 04:45, Nigel Cunningham wrote:
> > > 
> > > Add a helper which counts the number of patches of a type (all
> > > or userspace only) which are in TASK_UNINTERRUPTIBLE state.
> > > These tasks are signalled (just in case they leave that state at
> > > a later point), but we do not consider freezing to have failed
> > > if and when they do not enter the freezer.
> > > 
> > > Note that when they eventually leave TASK_UNINTERRUPTIBLE state,
> > > they will enter the refrigerator, but will immediately exit if
> > > we no longer want to freeze at that point.
> > 
> > I think we need to do something like this to prevent problems with
> > freezing under load.
> 
> That is dangerous... task in UNINTERRUPTIBLE may hold some lock,
> AFAICT.

Yes, and we have discussed that already, but frankly I'm still unconvinced. ;-)

> No, there's some simple bug in refrigerator, and I/we need to fix
> that. Signals work under load, so refrigerator should, too.

I don't think there's a bug as such.  The refrigerator is just very simple
and apparently does not cover all possible cases.

I think the problems with freezing tasks are generally related to
uninterruptible processes waiting for events that never happen.

IMHO we can try to defer calling freeze() for kernel threads until all of the
user space processes are frozen.  If that doesn't help, we'll need to treat
uninterruptible tasks in a special way, I'm afraid.

Greetings,
Rafael