One of the limiting factors in our Ganesha performance is that the NULL operation is going through the dupreq code. That can be easily fixed with a check that jumps to nocache.
One of the limiting factors in our ntirpc performance seems to be the call_replies tree that stores the xid of calls to match replies. Currently, we are using an RB tree. The XID advances sequentially. BTW, we have the same problem with fd. The fd advances sequentially. Performing sequential inserts, the AVL algorithm is 37.5% faster! https://refactoringlightly.wordpress.com/2017/10/29/performance-of-avl-red-black-trees-in-java/ There is one tree per connection. We don't really need to worry much about out of order replies. So the best structure would be a simpler tailq list. In the short term, we discussed hashing the XID before insertion. But that still has the rapid insertion/deletion issue. Apparently, insertions and deletions can be so slow that it takes a count of about 40 before AVL outperforms simple list. In the ping case, we'll never see more than 1. Its replies will always be sequential on a TCP connection. Do we know of any NFS case where we expect any RPC call to return behind more than 40 other calls on the same connection? Do we know of any NFS case where we expect to make 40 concurrent RPC calls on the same connection? [Remember, we are not talking about client to server calls. We are talking about server to client back-channel.] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
