In message <[EMAIL PROTECTED]>,Rainer Toebbicke writes: >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.
i guess i should clarify then. i havent seen it taking much cpu time. i didnt know how much wall clock was taken. that seems exceedingly bad considering that those packets will be making it back into the pool shortly via another route. apparently when afs was written kernel memory was a limited and valulable resource. that's no longer the guess but the code has never changed. >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. try rxperf, although its lwp and its mutex's are a bit simpler (they dont exist!) and might not show the same behavior. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
