| Message ID | 20120702111751.3ac78d2c@tlielax.poochiereds.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, 2012-07-02 at 11:17 -0400, Jeff Layton wrote: > nfs: broaden the cases where we use a non-blocking commit in releasepage > > Currently, we just do a non-blocking commit when called from kswapd, but > that still gives us some cases where we end up blocking after recursing > back into the filesystem. Instead, turn that check into a check for > PF_MEMALLOC so that we never block when trying to free memory in order to > satisfy an allocation. > > Signed-off-by: Jeff Layton <jlayton@redhat.com> > --- > fs/nfs/file.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/nfs/file.c b/fs/nfs/file.c > index 9075769..61d3670 100644 > --- a/fs/nfs/file.c > +++ b/fs/nfs/file.c > @@ -466,8 +466,8 @@ static int nfs_release_page(struct page *page, gfp_t gfp) > !(current->flags & PF_FSTRANS)) { > int how = FLUSH_SYNC; > > - /* Don't let kswapd deadlock waiting for OOM RPC calls */ > - if (current_is_kswapd()) > + /* Don't block if we're freeing for a memory allocation */ > + if (current->flags & PF_MEMALLOC) > how = 0; > nfs_commit_inode(mapping->host, how); > } Umm... So which process will actually call nfs_release_page() with GFP_KERNEL, but without the PF_MEMALLOC flag being set? -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com
On Mon, 2 Jul 2012 19:40:22 +0000 "Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote: > On Mon, 2012-07-02 at 11:17 -0400, Jeff Layton wrote: > > nfs: broaden the cases where we use a non-blocking commit in releasepage > > > > Currently, we just do a non-blocking commit when called from kswapd, but > > that still gives us some cases where we end up blocking after recursing > > back into the filesystem. Instead, turn that check into a check for > > PF_MEMALLOC so that we never block when trying to free memory in order to > > satisfy an allocation. > > > > Signed-off-by: Jeff Layton <jlayton@redhat.com> > > --- > > fs/nfs/file.c | 4 ++-- > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/fs/nfs/file.c b/fs/nfs/file.c > > index 9075769..61d3670 100644 > > --- a/fs/nfs/file.c > > +++ b/fs/nfs/file.c > > @@ -466,8 +466,8 @@ static int nfs_release_page(struct page *page, gfp_t gfp) > > !(current->flags & PF_FSTRANS)) { > > int how = FLUSH_SYNC; > > > > - /* Don't let kswapd deadlock waiting for OOM RPC calls */ > > - if (current_is_kswapd()) > > + /* Don't block if we're freeing for a memory allocation */ > > + if (current->flags & PF_MEMALLOC) > > how = 0; > > nfs_commit_inode(mapping->host, how); > > } > > Umm... So which process will actually call nfs_release_page() with > GFP_KERNEL, but without the PF_MEMALLOC flag being set? > Well...there are a number of callers of try_to_release_page with GFP_KERNEL that are not involved with reclaim: The migrate_page codepaths and the splice code, for instance. Also invalidate_complete_page2, which we call when invalidating an inode and maybe also when truncating? Those are almost certainly less traveled than the reclaim codepaths though.
diff --git a/fs/nfs/file.c b/fs/nfs/file.c index 9075769..61d3670 100644 --- a/fs/nfs/file.c +++ b/fs/nfs/file.c @@ -466,8 +466,8 @@ static int nfs_release_page(struct page *page, gfp_t gfp) !(current->flags & PF_FSTRANS)) { int how = FLUSH_SYNC; - /* Don't let kswapd deadlock waiting for OOM RPC calls */ - if (current_is_kswapd()) + /* Don't block if we're freeing for a memory allocation */ + if (current->flags & PF_MEMALLOC) how = 0; nfs_commit_inode(mapping->host, how); }