On Wed, Aug 13, 2014 at 12:08 AM, NeilBrown <neilb@xxxxxxx> wrote: > > > If the server restarts at an awkward time it is possible for write > requests to block waiting for the state manager to run. > If the state manager isn't already running a new thread will > need to be started which requires a GFP_KERNEL allocation > (for do_fork). > > If memory is short, that GFP_KERNEL allocation could block on the > writes going out via NFS, resulting in a deadlock. > > The easiest solution is to keep the manager thread running > always. I'm still trying to figure out what to do about this patch. There are 2 concerns: 1) If we're so low on memory that we can't even start a state manager thread, then how do we guarantee that the recovery can be completed? We rely on that state manager thread being able to allocate memory to perform the lease, session, open and lock recoveries. 2) Does allocating 1 thread per server really scale? Consider that each thread is going to be completely idle almost all the time. Wouldn't it be better to just preallocate only 1 thread, and then allocating others dynamically if we really do hit a situation where 2 or more servers are rebooting at the same time? Cheers Trond -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
