[OpenAFS-devel] .35 sec rx delay bug?

[chas williams - CONTRACTOR]

In message <455333F2.80600@pclella.cern.ch>,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.