On 3/12/18 6:25 PM, Matt Benjamin wrote:
If I understand correctly, we always insert records in xid order, and
xid is monotonically increasing by 1. I guess pings might come back
in any order,
No, they always come back in order. This is TCP. I've gone to some
lengths to fix the problem that operations were being executed in
arbitrary order. (As was reported in the past.)
For UDP, there is always the possibility of loss or re-ordering of
datagrams, one of the reasons for switching to TCP in NFSv3 (and
eliminating UDP in NFSv4).
Threads can still block in apparently random order, because of
timing variances inside FSAL calls. Should not be an issue here.
but if we assume xids retire in xid order also,
They do. Should be no variance. Eliminating the dupreq caching --
also using the rbtree -- significantly improved the timing.
Apparently picked the worst tree choice for this data, according to
computer science. If all you have is a hammer....
and keep
a window of 10000 records in-tree, that seems maybe like a reasonable
starting point for measuring this?
I've not tried 10,000 or 100,000 recently. (The original code
default sent 100,000.)
I've not recorded how many remain in-tree during the run.
In my measurements, using the new CLNT_CALL_BACK(), the client thread
starts sending a stream of pings. In every case, it peaks at a
relatively stable rate.
For 1,000, <4,000/s. For 100, 40,000/s. Fairly linear relationship.
By running multiple threads, I showed that each individual thread ran
roughly the same (on average). But there is some variance per run.
I only posted the 5 thread results, lowest and highest achieved.
My original message had up to 200 threads and 4 results, but I decided
such a long series was overkill, so removed them before sending.
That 4,000 and 40,000 per client thread was stable across all runs.
I wrote a gtest program (gerrit) that I think does the above in a
single thread, no locks, for 1M cycles (search, remove, insert). On
lemon, compiled at O2, the gtest profiling says the test finishes in
less than 150ms (I saw as low as 124). That's over 6M cycles/s, I
think.
What have you compared it to? Need a gtest of avl and tailq with the
same data. That's what the papers I looked at do....
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
