Thread (11 messages) flat view 11 messages, 6 authors, 2012-03-07

Re: TCP_STREAM performance regression on commit b3613118

From: Jason Wang <hidden>
Date: 2012-03-06 08:26:24
Also in: lkml

On 03/06/2012 04:11 PM, Feng Tang wrote:
On Thu, Mar 01, 2012 at 10:07:43PM -0500, David Miller wrote:
quoted
quoted
 From: Alex Shi[off-list ref]
 Date: Fri, 02 Mar 2012 10:45:17 +0800
 
quoted
 >  Add CC to tang feng, He is working on this issue.
 
 Is he?  I'm pretty sure this is due to the TCP receive window growing
 issue Eric Dumazet, Neal Cardwell and I are discussing in the thread
 starting at:
 
 http://marc.info/?l=linux-netdev&m=132916352815286&w=2
Yes, probably, as we did find some clue related with the tcp_r/wmem.

Here is the regression we found:
On some machines, we found there is about 10% resgression of netperf
TCP-64K loopback test between 3.2 and 3.3-rc1. The exact test is:
./netperf -t TCP_STREAM -l 60 -H 127.0.0.1 -i 50,3 -I 99,5 -- -s 32768 -S 32768 -m 4096


The test machine is a 2 socket Quad Core Core 2 Duo server(2.66GHz) with
8 GB RAM. Following are the debug info (ifconfig/netstat -s/tcp_rwmem)
before and after the test:

The most obvious differences I can see are:
1) 311 GB vs 241 GB from ifconfig
2) the difference of the tcp_r/wmem
Hi:

Could you try the newest kernel? Looks like the difference has been 
already fixed by commit c43b874d5d714f271b80d4c3f49e05d0cbf51ed2.

Thanks
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help