linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>,
	trond.myklebust@netapp.com, smfrench@gmail.com,
	linux-pm@lists.linux-foundation.org, linux-cifs@vger.kernel.org,
	linux-nfs@vger.kernel.org, john@calva.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] freezer: make fake_signal_wake_up wake TASK_KILLABLE tasks too
Date: Wed, 26 Oct 2011 15:55:48 -0400	[thread overview]
Message-ID: <20111026155548.4a7c3dd8@corrin.poochiereds.net> (raw)
In-Reply-To: <201110112114.28478.rjw@sisk.pl>

On Tue, 11 Oct 2011 21:14:28 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Tuesday, October 11, 2011, Jeff Layton wrote:
> > On Tue, 11 Oct 2011 08:18:48 +0200
> > Pavel Machek <pavel@ucw.cz> wrote:
> > 
> > > 
> > > Hi!
> > > 
> > > > TASK_KILLABLE is often used to put tasks to sleep for quite some time.
> > > > One of the most common uses is to put tasks to sleep while waiting for
> > > > replies from a server on a networked filesystem (such as CIFS or NFS).
> > > > 
> > > > Unfortunately, fake_signal_wake_up does not currently wake up tasks
> > > > that are sleeping in TASK_KILLABLE state. This means that even if the
> > > > code were in place to allow them to freeze while in this sleep, it
> > > > wouldn't work anyway.
> > > > 
> > > > This patch changes this function to wake tasks in this state as well.
> > > > This should be harmless -- if the code doing the sleeping doesn't have
> > > > handling to deal with freezer events, it should just go back to sleep.
> > > 
> > > I'm pretty sure this will break something; but that does not mean it
> > > is bad idea, just that it should be merged early and tested a lot.
> > > 
> > 
> > FWIW, I looked at most of the places in the kernel that do
> > TASK_KILLABLE sleeps and they look like they'll handle this correctly.
> > The main one I wasn't sure about was mem_cgroup_handle_oom(), but I
> > think it'll do the right thing too. I certainly could have missed
> > something though...
> > 
> > In any case, would you mind merging this via the linux-pm tree for 3.2?
> 
> I will push it for 3.2.
> 

Hi Rafael,

Trond asked if you would also be willing to push patches 3 and 4 in
this series for 3.2 as well [1]? Note that patch #4 got another revision so
we'll want to make sure that you get that one. I can resend the
nfs/sunrpc patches if that will help...

[1]: I think Steve F is going to push patch #2, so that one shouldn't
be an issue. 

-- 
Jeff Layton <jlayton@redhat.com>

  reply	other threads:[~2011-10-26 19:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-28 11:52 [PATCH 0/4] allow freezing of tasks with netfs calls in flight Jeff Layton
2011-09-28 11:52 ` [PATCH 1/4] freezer: make fake_signal_wake_up wake TASK_KILLABLE tasks too Jeff Layton
2011-10-11  6:18   ` Pavel Machek
2011-10-11 10:10     ` Jeff Layton
2011-10-11 19:14       ` Rafael J. Wysocki
2011-10-26 19:55         ` Jeff Layton [this message]
2011-10-27 20:21           ` Rafael J. Wysocki
2011-10-27 20:22             ` [linux-pm] " Rafael J. Wysocki
2011-10-27 20:26               ` Steve French
2011-09-28 11:52 ` [PATCH 2/4] cifs, freezer: add wait_event_freezekillable and have cifs use it Jeff Layton
2011-09-29  4:28   ` Steve French
2011-09-29 10:41     ` Jeff Layton
2011-09-29 16:39       ` Steve French
2011-09-29 17:29         ` Jeff Layton
2011-09-28 11:52 ` [PATCH 3/4] sunrpc: make rpc_wait_bit_killable handle freeze events Jeff Layton
2011-10-11  6:19   ` Pavel Machek
2011-10-11 10:12     ` Jeff Layton
2011-10-11 12:52       ` Myklebust, Trond
2011-10-11 13:14         ` Jeff Layton
2011-09-28 11:52 ` [PATCH 4/4] nfs: make TASK_KILLABLE sleeps attempt to freeze Jeff Layton
2011-10-19 15:18   ` [PATCH 4/4] nfs: make TASK_KILLABLE sleeps attempt to freeze (try #2) Jeff Layton
2011-10-11  6:18 ` [PATCH 0/4] allow freezing of tasks with netfs calls in flight Pavel Machek
2011-10-11 10:05   ` Jeff Layton
2011-10-11 19:19     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111026155548.4a7c3dd8@corrin.poochiereds.net \
    --to=jlayton@redhat.com \
    --cc=john@calva.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    --cc=smfrench@gmail.com \
    --cc=trond.myklebust@netapp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).