| Message ID | 20220322011618.1052288-1-trondmy@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Crossing our fingers is not a strategy | expand |
On Tue, 22 Mar 2022, trondmy@kernel.org wrote: > From: Trond Myklebust <trond.myklebust@hammerspace.com> > > We'd like to avoid GFP_NOWAIT whenever possible, because it has no fall- > back reclaim strategy for dealing with a failure of the initial > allocation. I'm not sure I entirely agree with that. GFP_NOWAIT will ensure kswapd runs on failure, so waiting briefly and retrying (which sunrpc does on -ENOMEM (at least ni call_refreshresult) is a valid fallback. However, I do like the new rpc_task_gfp_mask() and that fact that you have used it quite widely. So: looks good to me. I haven't carefully reviewed each patch enough to say Reviewed-by, but I did see an easy problems. Thanks, NeilBrown
On Thu, 2022-03-24 at 09:57 +1100, NeilBrown wrote: > On Tue, 22 Mar 2022, trondmy@kernel.org wrote: > > From: Trond Myklebust <trond.myklebust@hammerspace.com> > > > > We'd like to avoid GFP_NOWAIT whenever possible, because it has no > > fall- > > back reclaim strategy for dealing with a failure of the initial > > allocation. > > I'm not sure I entirely agree with that. GFP_NOWAIT will ensure > kswapd > runs on failure, so waiting briefly and retrying (which sunrpc does > on > -ENOMEM (at least ni call_refreshresult) is a valid fallback. > > However, I do like the new rpc_task_gfp_mask() and that fact that you > have used it quite widely. > > So: looks good to me. I haven't carefully reviewed each patch enough > to > say Reviewed-by, but I did see an easy problems. Thanks Neil!
From: Trond Myklebust <trond.myklebust@hammerspace.com> We'd like to avoid GFP_NOWAIT whenever possible, because it has no fall- back reclaim strategy for dealing with a failure of the initial allocation. At the same time, memory pools appear to be suboptimal as an allocation strategy when used with anything other than GFP_NOWAIT, since they cause threads to hang upon failure. This patch series therefore aims to demote the mempools to being a strategy of last resort, with the primary allocation strategy being to use the underlying slabs. While we're at it, we want to ensure that rpciod, xprtiod and nfsiod all use the same allocation strategy, so that the latter two don't thwart our ability to complete writeback RPC calls by getting blocked in the mm layer. Trond Myklebust (9): NFS: Fix memory allocation in rpc_malloc() NFS: Fix memory allocation in rpc_alloc_task() SUNRPC: Fix unx_lookup_cred() allocation SUNRPC: Make the rpciod and xprtiod slab allocation modes consistent NFS: nfsiod should not block forever in mempool_alloc() NFS: Avoid writeback threads getting stuck in mempool_alloc() NFSv4/pnfs: Ensure pNFS allocation modes are consistent with nfsiod pNFS/flexfiles: Ensure pNFS allocation modes are consistent with nfsiod pNFS/files: Ensure pNFS allocation modes are consistent with nfsiod fs/nfs/filelayout/filelayout.c | 2 +- fs/nfs/flexfilelayout/flexfilelayout.c | 50 +++++++++++--------------- fs/nfs/internal.h | 7 ++++ fs/nfs/nfs42proc.c | 2 +- fs/nfs/pagelist.c | 10 +++--- fs/nfs/pnfs.c | 39 +++++++++----------- fs/nfs/pnfs_nfs.c | 8 +++-- fs/nfs/write.c | 34 +++++++++--------- include/linux/nfs_fs.h | 2 +- include/linux/sunrpc/sched.h | 1 + net/sunrpc/auth_unix.c | 18 +++++----- net/sunrpc/backchannel_rqst.c | 8 ++--- net/sunrpc/rpcb_clnt.c | 4 +-- net/sunrpc/sched.c | 31 ++++++++++------ net/sunrpc/socklib.c | 3 +- net/sunrpc/xprt.c | 5 +-- net/sunrpc/xprtsock.c | 11 +++--- 17 files changed, 123 insertions(+), 112 deletions(-)