On Apr 13, 2011, at 10:22 AM, Trond Myklebust wrote: > On Wed, 2011-04-13 at 10:02 -0400, Jeff Layton wrote: >> We could put the rpc_rqst's into a slabcache, and give each rpc_xprt a >> mempool with a minimum number of slots. Have them all be allocated with >> GFP_NOWAIT. If it gets a NULL pointer back, then the task can sleep on >> the waitqueue like it does today. Then, the clients can allocate >> rpc_rqst's as they need as long as memory holds out for it. >> >> We have the reserve_xprt stuff to handle congestion control anyway so I >> don't really see the value in the artificial limits that the slot table >> provides. >> >> Maybe I should hack up a patchset for this... > > This issue has come up several times recently. My preference would be to > tie the availability of slots to the TCP window size, and basically say > that if the SOCK_ASYNC_NOSPACE flag is set on the socket, then we hold > off allocating more slots until we get a ->write_space() callback which > clears that flag. I am scoping the dynamic rpc_slot allocation work and plan to prototype. -->Andy > > For the RDMA case, we can continue to use the current system of a fixed > number of preallocated slots. > > Cheers > Trond > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@xxxxxxxxxx > www.netapp.com > > -- > 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 -- 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
