From: David Miller <davem@davemloft.net> Date: 2012-02-17 18:33:34
From: Eric Dumazet <redacted>
Date: Fri, 17 Feb 2012 10:50:39 +0100
Le vendredi 17 février 2012 à 16:18 +0800, Alex,Shi a écrit :
quoted
The tcp_stream loop back performance has about 10% drop on the
commitment on our core2 2 sockets server. This commit has 2
parents(7505afe28, 5983fe), but both of them have no regression. So
guess the impact just happened when this 2 parents joint. That beyond
our capability to dig it more.
Any ideas?
Most probably the more accurate truesize determination is responsible of
this tcp regression, since some prior assumptions might be wrong.
Want to give more information on the workload ?
Is it a 32 or 64 bit kernel ?
On Fri, 2012-02-17 at 13:33 -0500, David Miller wrote:
From: Eric Dumazet <redacted>
Date: Fri, 17 Feb 2012 10:50:39 +0100
quoted
Le vendredi 17 février 2012 à 16:18 +0800, Alex,Shi a écrit :
quoted
The tcp_stream loop back performance has about 10% drop on the
commitment on our core2 2 sockets server. This commit has 2
parents(7505afe28, 5983fe), but both of them have no regression. So
guess the impact just happened when this 2 parents joint. That beyond
our capability to dig it more.
Any ideas?
Most probably the more accurate truesize determination is responsible of
this tcp regression, since some prior assumptions might be wrong.
Want to give more information on the workload ?
Is it a 32 or 64 bit kernel ?
It is 64 bit kernel. Currently we only care 64bit.
Will try to bring more statistic after our lab recovered.
On Fri, 2012-02-17 at 13:33 -0500, David Miller wrote:
From: Eric Dumazet <redacted>
Date: Fri, 17 Feb 2012 10:50:39 +0100
quoted
Le vendredi 17 février 2012 à 16:18 +0800, Alex,Shi a écrit :
quoted
The tcp_stream loop back performance has about 10% drop on the
commitment on our core2 2 sockets server. This commit has 2
parents(7505afe28, 5983fe), but both of them have no regression. So
guess the impact just happened when this 2 parents joint. That beyond
our capability to dig it more.
Any ideas?
Most probably the more accurate truesize determination is responsible of
this tcp regression, since some prior assumptions might be wrong.
Want to give more information on the workload ?
Is it a 32 or 64 bit kernel ?
That's great!
May my language make you confusing. Actually, Feng is doing
investigation on this issue. Since you fund out the reason, it saved his
work. :)
That's great!
May my language make you confusing. Actually, Feng is doing
investigation on this issue. Since you fund out the reason, it saved his
work. :)
Actually it would be great if you or Feng could post the exact tests
done and numbers so that we can make sure this is the tracked issue.
Thanks
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
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.
Most likely yes.
tcp_rmem
4096 87380 87380
tcp_wmem
4096 16384 65536
Is way pessimistic :(
From: Rick Jones <hidden> Date: 2012-03-06 18:24:00
On 03/06/2012 12:11 AM, Feng Tang wrote:
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
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.
Yeah, with the newest kernel, the regression of this simple test is gone,
the performance difference with 3.2 kernel is now only about 1-2%. Thanks
for the info.
- Feng