On Wed, 2022-03-16 at 12:53 +1100, NeilBrown wrote: > On Wed, 16 Mar 2022, trondmy@xxxxxxxxxx wrote: > > From: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> > > > > When allocating memory, it should be safe to always use GFP_KERNEL, > > since both swap tasks and asynchronous tasks will regulate the > > allocation mode through the struct task flags. > > 'struct task_struct' flags can only enforce NOFS, NOIO, or MEMALLOC. > They cannot prevent waiting altogether. > We need rpciod task to not block waiting for memory. If they all do, > then there will be no thread free to handle the replies to WRITE > which > would allow swapped-out memory to be freed. > > As the very least the rescuer thread mustn't block, so the use of > GFP_NOWAIT could depend on current_is_workqueue_rescuer(). > > Was there some problem you saw caused by the use of GFP_NOWAIT ?? > There is no point in trying to give rpciod stronger protection than what is given to the standard memory reclaim processes. The VM does not have a requirement that writepages() and its ilk to be non-waiting and non-blocking, nor does it require that the threads that help service those writebacks be non-blocking. We wouldn't be able to do things like create a new socket to reconnect to the server if we couldn't perform blocking allocations from rpciod. None of the socket creation APIs allow you to pass in a gfp flag mask. What we do require in this situation, is that we must not recurse back into NFS. This is why we have the memalloc_nofs_save() / memalloc_nofs_restore() protection in various places, including rpc_async_schedule() and rpc_execute(). That still allows the VM to actively perform direct reclaim, and to start I/O against block devices when in a low memory situation. Why would we not want it to do that? The alternative with GFP_NOWAIT is to stall the RPC I/O altogether when in a low memory situation, and to cross our fingers that something else causes memory to be freed up. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
