[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200705292355.15563.rjw@sisk.pl>
Date: Tue, 29 May 2007 23:55:14 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Pavel Machek <pavel@....cz>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Gautham R Shenoy <ego@...ibm.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Nigel Cunningham <nigel@...el.suspend2.net>,
Oleg Nesterov <oleg@...sign.ru>
Subject: Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default
On Tuesday, 29 May 2007 14:48, Pavel Machek wrote:
> Hi!
>
> > > Well.. it can write anywhere it wants (filesystem or not) as long as
> > > the system is not going to be confused after resume by its caches not
> > > matching on-disk state. I'd prefer it not to write anywhere at all.
> >
> > OK
> >
> > Please have a look at the current version of the patch (appended).
> >
> > I have followed the Nigel's suggestion not to change the current behavior
> > in this patch (I'll add a couple of patches removing the freezability from
> > some kernel threads), with one exception: I couldn't figure out any reason
> > to have try_to_freeze() called in net/sunrpc/svcsock.c:svc_recv() .
>
> It probably broke suspend at some point... leave it there. Processes
> can stay in D period, waiting for NFS server to come back.
>
> and yes, we want nfs threads frozen, too (and anything that talks to
> network). Speaking to nfs servers while we are suspending the machine
> is not nice, and if that continues after snapshot, we'll act as a very
> confused machine to the outside...
OK, I've added set_freezable() to the NFS-related threads.
[Updated patch is in the reply to Nigel.]
Greetings,
Rafael
-
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