On Wed, 27 Jun 2012 19:56:38 +0000 "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > On Wed, 2012-06-27 at 15:28 -0400, Jeff Layton wrote: > > On Wed, 27 Jun 2012 18:43:56 +0000 > > "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > > If there really is no alternative to freeing the socket, then the only > > real fix I can see is to set PF_MEMALLOC when we go to create it and > > then reset it afterward. That's a pretty ugly fix though... > > I can think of 2 possible alternatives: > > 1. Use the PF_FSTRANS flag to tell nfs_release_page that this is a > direct reclaim from rpciod. Hmm...that's a bit indiscriminate, isn't it? Looks like only XFS uses that flag now... Suppose we're in some XFS allocation and then want to commit a NFS page to satisfy it. There's no real reason we couldn't but that would prevent it... > 2. Add a 'congested' flag to the rpc client that could tell reclaim > type operations to give up if a socket allocation is in > progress. > That's not a bad idea. That has the benefit of only skipping reclaim when it's directly associated with the socket being reconnected. Seems like that would have to hang off of the rpc_xprt, but we could do something along those lines. Presumably Mel's swap-over-nfs patches could be converted to do something similar instead of using PF_MEMALLOC there too. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
