From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Nigel Cunningham <nigel@suspend2.net>
Subject: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.
Date: Mon, 6 Feb 2006 00:56:43 +0100
User-Agent: KMail/1.9.1
Cc: suspend2-devel@lists.suspend2.net, Pavel Machek <pavel@ucw.cz>,
       linux-kernel@vger.kernel.org
References: <20060201113710.6320.68289.stgit@localhost.localdomain> <200602041818.57278.rjw@sisk.pl> <200602060943.19774.nigel@suspend2.net>
In-Reply-To: <200602060943.19774.nigel@suspend2.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200602060056.43672.rjw@sisk.pl>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2788
Lines: 67

Hi,

On Monday 06 February 2006 00:43, Nigel Cunningham wrote:
> On Sunday 05 February 2006 03:18, Rafael J. Wysocki wrote:
> > On Saturday 04 February 2006 12:41, Nigel Cunningham wrote:
> > > On Saturday 04 February 2006 21:38, Rafael J. Wysocki wrote:
> > > > > > My personal view is that:
> > > > > > 1) turning the freezing of kernel threads upside-down is not
> > > > > > necessary and would cause problems in the long run,
> > > > >
> > > > > Upside down?
> > > >
> > > > I mean now they should freeze voluntarily and your patches change
> > > > that so they would have to be created as non-freezeable if need be,
> > > > AFAICT.
> > >
> > > Ah. Now I'm on the same page. Lost the context.
> > >
> > > > > > 2) the todo lists are not necessary and add a lot of complexity,
> > > > >
> > > > > Sorry. Forgot about this. I liked it for solving the SMP problem,
> > > > > but IIRC, we're downing other cpus before this now, so that issue
> > > > > has gone away. I should check whether I'm right there.
> > > > >
> > > > > > 3) trying to treat uninterruptible tasks as non-freezeable
> > > > > > should better be avoided (I tried to implement this in swsusp
> > > > > > last year but it caused vigorous opposition to appear, and it
> > > > > > was not Pavel ;-))
> > > > >
> > > > > I'm not suggesting treating them as unfreezeable in the fullest
> > > > > sense. I still signal them, but don't mind if they don't respond.
> > > > > This way, if they do leave that state for some reason (timeout?)
> > > > > at some point, they still get frozen.
> > > >
> > > > Yes, that's exactly what I wanted to do in swsusp. ;-)
> > >
> > > Oh. What's Pavel's solution? Fail freezing if uninterruptible threads
> > > don't freeze?
> >
> > Yes.
> >
> > AFAICT it's to avoid situations in which we would freeze having a
> > process in the D state that holds a semaphore or a mutex neded for
> > suspending or resuming devices (or later on for saving the image etc.).
> >
> > [I didn't answer this question previously, sorry.]
> 
> S'okay. This thread is an ocotpus :)
> 
> Are there real life examples of this? I can't think of a single time that 
> I've heard of something like this happening. I do see rare problems with 
> storage drivers not having driver model support right, and thereby causing 
> hangs, but that's brokenness in a completely different way.
> 
> In short, I'm wondering if (apart from the forking issue), this is a straw 
> man.

It doesn't seem to be very probable to me too, but I take this argument
as valid.

Greetings,
Rafael
-
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/