With N=100000 and num_calls=1000000, on Lemon, test_rbt averages 2.8M reqs/s. That's about half the rate when N=10000, which I think is expected. If this is really an available rbt in-order search-remove-insert retire rate when N is 100000, my intuition would be it's sufficiently fast not to be the bottleneck your result claims, and I think it's necessary to understand why.
Matt On Sun, Mar 25, 2018 at 6:17 PM, Matt Benjamin <mbenj...@redhat.com> wrote: > 1 What is the peak outstanding size of outstanding calls > > 1.1 if e.g. > 100k is that correct: as last week, why would a sensible > client issue more than e.g. 1000 calls without seeing replies? > > 1.3 if outstanding calls is <= 10000, why can test_rbt retire millions of > duty cycles / s in that scenario? > > 2 what does the search workload look like when replies are mixed with calls? > Ie bidirectional rpc this is intended for? > > 2.2 Hint: xid dist is not generally sorted; client defines only its own > issue order, not reply order nor peer xids; why is it safe to base reply > matching around xids being in sorted order? > > Matt > > On Sun, Mar 25, 2018, 1:40 PM William Allen Simpson > <william.allen.simp...@gmail.com> wrote: >> >> On 3/24/18 7:50 AM, William Allen Simpson wrote: >> > Noting that the top problem is exactly my prediction by knowledge of >> > the code: >> > clnt_req_callback() opr_rbtree_insert() >> > >> > The second is also exactly as expected: >> > >> > svc_rqst_expire_insert() opr_rbtree_insert() svc_rqst_expire_cmpf() >> > >> > These are both inserted in ascending order, sorted in ascending order, >> > and removed in ascending order.... >> > >> > QED: rb_tree is a poor data structure for this purpose. >> >> I've replaced those 2 rbtrees with TAILQ, so that we are not >> spending 49% of the time there anymore, and am now seeing: >> >> rpcping tcp localhost count=1000 threads=1 workers=5 (port=2049 >> program=100003 version=3 procedure=0): mean 151800.6287, total 151800.6287 >> rpcping tcp localhost count=1000 threads=1 workers=5 (port=2049 >> program=100003 version=3 procedure=0): mean 167828.8817, total 167828.8817 >> >> This is probably good enough for now. Time to move on to >> more interesting things. >> >> >> ------------------------------------------------------------------------------ >> 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 -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 ------------------------------------------------------------------------------ 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
