| Message ID | 1422145127-81838-2-git-send-email-trond.myklebust@primarydata.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Jan 24, 2015, at 7:18 PM, Trond Myklebust <trond.myklebust@primarydata.com> wrote: > We should be safe now, as long as we don't do GFP_IO or higher allocations Should the GFP flags in xprt_rdma_allocate() reflect this change as well? The non-swap case uses GFP_NOFS currently, and the swap case does not include GFP_MEMALLOC. These choices might be out of date. If so I can submit a patch on top of my existing for-3.20 series that changes xprt_rdma_allocate() to use the same flags as rpc_malloc(). > Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> > --- > net/sunrpc/sched.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c > index 4f65ec28d2b4..b91fd9c597b4 100644 > --- a/net/sunrpc/sched.c > +++ b/net/sunrpc/sched.c > @@ -844,10 +844,10 @@ static void rpc_async_schedule(struct work_struct *work) > void *rpc_malloc(struct rpc_task *task, size_t size) > { > struct rpc_buffer *buf; > - gfp_t gfp = GFP_NOWAIT | __GFP_NOWARN; > + gfp_t gfp = GFP_NOIO | __GFP_NOWARN; > > if (RPC_IS_SWAPPER(task)) > - gfp |= __GFP_MEMALLOC; > + gfp = __GFP_MEMALLOC | GFP_NOWAIT | __GFP_NOWARN; > > size += sizeof(struct rpc_buffer); > if (size <= RPC_BUFFER_MAXSIZE) > -- > 2.1.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jan 25, 2015 at 3:11 PM, Chuck Lever <chuck.lever@oracle.com> wrote: > > > On Jan 24, 2015, at 7:18 PM, Trond Myklebust <trond.myklebust@primarydata.com> wrote: > > > We should be safe now, as long as we don't do GFP_IO or higher allocations > > Should the GFP flags in xprt_rdma_allocate() reflect this change > as well? The non-swap case uses GFP_NOFS currently, and the GFP_NOFS or GFP_NOWAIT? If the former, then that would be yet further justification for PATCH 1/2. > swap case does not include GFP_MEMALLOC. These choices might be > out of date. > > If so I can submit a patch on top of my existing for-3.20 series > that changes xprt_rdma_allocate() to use the same flags as > rpc_malloc(). Yes. I think GFP_NOIO is the more conservative (and correct) approach here, rather than GFP_NOFS. In particular it means that we won't trigger any new swap-over-nfs activity.
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c index 4f65ec28d2b4..b91fd9c597b4 100644 --- a/net/sunrpc/sched.c +++ b/net/sunrpc/sched.c @@ -844,10 +844,10 @@ static void rpc_async_schedule(struct work_struct *work) void *rpc_malloc(struct rpc_task *task, size_t size) { struct rpc_buffer *buf; - gfp_t gfp = GFP_NOWAIT | __GFP_NOWARN; + gfp_t gfp = GFP_NOIO | __GFP_NOWARN; if (RPC_IS_SWAPPER(task)) - gfp |= __GFP_MEMALLOC; + gfp = __GFP_MEMALLOC | GFP_NOWAIT | __GFP_NOWARN; size += sizeof(struct rpc_buffer); if (size <= RPC_BUFFER_MAXSIZE)
We should be safe now, as long as we don't do GFP_IO or higher allocations Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> --- net/sunrpc/sched.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)