chas williams - CONTRACTOR wrote:
i dont know much about rxi_TrimDataBufs(). it looks like its trying to get empty rx buffers (due to a "short" read i guess) into the queue faster. that's going to happen anyway. benchmark it but i dont think i have every seen any traces showing significant time being spent in this code path.
Well, it does: the point is that the trim also applies to ACKs received. While releasing the excess buffers, the code actually *does* take locks often enough to delay the ACK where rule number one would be to process asap it in order to keep the queues short and the window open. I've seen 1ms delays through RX tracing, enough to close the window.
By commenting out this call I got a performance boost of almost 50% on an RX transfer with disk I/O - i.e. the one that suffers most of long queues: >90 MB/s instead of 65 MB/s on the same switch. Admittedly, that's not more yet than a smoking gun. In particular the tracing has it's own weaknesses.
-- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rainer Toebbicke European Laboratory for Particle Physics(CERN) - Geneva, Switzerland Phone: +41 22 767 8985 Fax: +41 22 767 7155 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
