On Wed, 2012-06-27 at 16:19 -0400, Jeff Layton wrote:
> 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...
So do all the GFP_NOFS allocations. How is this any different?
> > 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.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
