Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly?

Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly?

[Skywind]

Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly?

Test Backgroud:
CPU: Intel P4
Mem: 512Mb
The /etc/sysctl.conf and other haven't touch anything.

I found a strange question: when I use kernel 2.6.11, the value of
/proc/sys/net/ipv4/tcp_max_syn_backlog is 256,
while kernel 2.6.10 on same computer the value is 1024.

So I check the net/ipv4/[tcp.c, tcp_ipv4.c] and know when Mem >= 256Mb
the tcp_max_syn_backlog will be set to 1024,
but it is 256 in my test above.

Some other variables that should be adjust all together with
tcp_max_syn_backlog are:
ip_local_port_range
tcp_max_tw_buckets
tcp_max_orphans
But they don't be adjust to correctly value(refer to net/ipv4/tcp.c) all.

It seems that kernel don't adjust these value automatic, is this a bug?

I guess the mechanism of tcp.c in 2.6.11 have some changes(between
2.6.10), and it conduce to this result,
Is this guess correctly?



Xu Gang (Skywind)
2005/06/06

Re: Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly?

[Skywind]

Any one know the reason?

I think the subject may change to 
"Is kernel 2.6.11 havn't set /proc network variable"
or
"Kernel 2.6.11 havn't set /proc network variable correctly by mem size"


> Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly?
>
> Test Backgroud:
> CPU: Intel P4
> Mem: 512Mb
> The /etc/sysctl.conf and other haven't touch anything.
>
> I found a strange question: when I use kernel 2.6.11, the value of
> /proc/sys/net/ipv4/tcp_max_syn_backlog is 256,
> while kernel 2.6.10 on same computer the value is 1024.
>
> So I check the net/ipv4/[tcp.c, tcp_ipv4.c] and know when Mem >= 256Mb
> the tcp_max_syn_backlog will be set to 1024,
> but it is 256 in my test above.

> Some other variables that should be adjust all together with
> tcp_max_syn_backlog are:
> ip_local_port_range
> tcp_max_tw_buckets
> tcp_max_orphans
> But they don't be adjust to correctly value(refer to net/ipv4/tcp.c) all.
>
> It seems that kernel don't adjust these value automatic, is this a bug?
>
> I guess the mechanism of tcp.c in 2.6.11 have some changes(between
> 2.6.10), and it conduce to this result,
> Is this guess correctly?



> Xu Gang (Skywind)
> 2005/06/06

Re: Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly?

[Andi Kleen]

Skywind <gnuwind@gmail.com> writes:
>
> It seems that kernel don't adjust these value automatic, is this a bug?
>
> I guess the mechanism of tcp.c in 2.6.11 have some changes(between
> 2.6.10), and it conduce to this result,
> Is this guess correctly?

Yes, there were some changes here when it was converted to a common
function for all hash tables (alloc_large_system_hash - the function
with the argument list from hell).  Anyways, here's a quick fix.

DaveM for your consideration.

Adjust TCP mem order check to new alloc_large_system_hash

Signed-off-by: Andi Kleen <ak@suse.de>

--- linux-2.6.11-work/net/ipv4/tcp.c~	2005-03-02 08:37:51.000000000 +0100
+++ linux-2.6.11-work/net/ipv4/tcp.c	2005-06-11 12:16:22.000000000 +0200
@@ -2337,7 +2337,7 @@
 			(tcp_bhash_size * sizeof(struct tcp_bind_hashbucket));
 			order++)
 		;
-	if (order > 4) {
+	if (order >= 4) {
 		sysctl_local_port_range[0] = 32768;
 		sysctl_local_port_range[1] = 61000;
 		sysctl_tcp_max_tw_buckets = 180000;

Re: Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly?

[David S. Miller]

From: Andi Kleen <ak@muc.de>
Date: Sat, 11 Jun 2005 12:25:08 +0200

> Yes, there were some changes here when it was converted to a common
> function for all hash tables (alloc_large_system_hash - the function
> with the argument list from hell).  Anyways, here's a quick fix.
> 
> DaveM for your consideration.
> 
> Adjust TCP mem order check to new alloc_large_system_hash
> 
> Signed-off-by: Andi Kleen <ak@suse.de>

I just reread those NUMA changes, and they changed the heuristics
for sizing things at the same time as moving over to the
alloc_large_system_hash() change.

The change was to move from (21 - PAGE_SHIFT) and (23 - PAGE_SHIFT)
to (25 - PAGE_SHIFT) and (27 - PAGE_SHIFT) respectively.

This is the part of the NUMA TCP changes that made the sysctl setting
behavior differ.

Andi's patch is the least intrusive fix for 2.6.12, so I will
apply it.  But longer term these heuristics need to be revisited
as a whole.