Hi Neil, On Tue, Sep 16, 2014 at 1:31 AM, NeilBrown <neilb@xxxxxxx> wrote: > Now that nfs_release_page() doesn't block indefinitely, other deadlock > avoidance mechanisms aren't needed. > - it doesn't hurt for kswapd to block occasionally. If it doesn't > want to block it would clear __GFP_WAIT. The current_is_kswapd() > was only added to avoid deadlocks and we have a new approach for > that. > - memory allocation in the SUNRPC layer can very rarely try to > ->releasepage() a page it is trying to handle. The deadlock > is removed as nfs_release_page() doesn't block indefinitely. > > So we don't need to set PF_FSTRANS for sunrpc network operations any > more. Jeff Layton and I had a little discussion about this earlier today. The issue that Jeff raised was that these 1 second waits, although they will eventually complete, can nevertheless have a cumulative large effect if, say, the reason why we're not making progress is that we're being called as part of a socket reconnect attempt in xs_tcp_setup_socket(). In that case, any attempts to call nfs_release_page() on pages that need to use that socket, will result in a 1 second wait, and no progress in satisfying the allocation attempt. Our conclusion was that we still need the PF_FSTRANS in order to deal with that case, where we need to actually circumvent the new wait in order to guarantee progress on the task of allocating and connecting the new socket. Comments? Cheers Trond -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
