With N=10 and num_calls=100, on Lemon, test_rbt averages 2.8M
reqs/s. That's about half the rate when N=1, which I think is
expected. If this is really an available rbt in-order
search-remove-insert retire rate when N is 10, my intuition would
be it's sufficiently fast not to be
>From Matt Benjamin :
Matt Benjamin has uploaded this change for review. (
https://review.gerrithub.io/405191
Change subject: gtest: adjust linkage for nfs_core
..
gtest: adjust linkage for nfs_core
>From Matt Benjamin :
Matt Benjamin has uploaded this change for review. (
https://review.gerrithub.io/405190
Change subject: 9p. gtest: qualify export identifier in struct _9p_fid
..
9p. gtest: qualify
>From Matt Benjamin :
Matt Benjamin has uploaded this change for review. (
https://review.gerrithub.io/405189
Change subject: test_rbt: time explicitly, default to 1M cycles
..
test_rbt: time explicitly,
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 <= 1, why can test_rbt retire millions of
duty cycles / s in that
On 3/23/18 1:30 PM, William Allen Simpson wrote:
Ran some apples to apples comparisons today V2.7-dev.5:
Without the client-side rbtrees, rpcping works a lot better:
Ganesha (worst, best):
rpcping tcp localhost count=1000 threads=1 workers=5 (port=2049 program=13
version=3
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