* Re: Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly? [not found] ` <75052be705060607106a6c0882@mail.gmail.com> @ 2005-06-11 10:25 ` Andi Kleen 2005-06-13 21:24 ` David S. Miller 0 siblings, 1 reply; 2+ messages in thread From: Andi Kleen @ 2005-06-11 10:25 UTC (permalink / raw) To: Skywind; +Cc: davem, casavan, linux-kernel, netdev 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; ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly? 2005-06-11 10:25 ` Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly? Andi Kleen @ 2005-06-13 21:24 ` David S. Miller 0 siblings, 0 replies; 2+ messages in thread From: David S. Miller @ 2005-06-13 21:24 UTC (permalink / raw) To: ak; +Cc: gnuwind, casavan, linux-kernel, netdev 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. ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-06-13 21:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <75052be7050606070691c302d@mail.gmail.com>
[not found] ` <75052be705060607106a6c0882@mail.gmail.com>
2005-06-11 10:25 ` Is kernel 2.6.11 adjust tcp_max_syn_backlog incorrectly? Andi Kleen
2005-06-13 21:24 ` David S. Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).