quoted

quoted

quoted

quoted

On Wed, 29 Oct 2003 13:33:15 +0100, Andi Kleen [off-list ref] said:

  Andi> On Tue, 28 Oct 2003 22:58:00 -0800
  Andi> David Mosberger [off-list ref] wrote:

  >> Also, it appears that current SuSE kernels do indeed have a
  >> net.core.somaxconn sysctl to let a sysadmin choose a larger SOMAXCONN
  >> value.

  Andi> Yes I did that patch some time ago for some server who needed
  Andi> it. If there is interest I can submit it for 2.6. But I'm not
  Andi> sure it fits the "important bug fixes only" rule.

Yes, I think the patch should be (re-)submitted.  It certainly fixes a
performance bug.  At the moment, in-kernel servers are at an unfair
advantage over user-space servers for this reason.

In my opinion, SOMAXCONN should also be bumped, but that's less
critical if there is a sysctl to override the default value (plus I
only have a hand-wavy argument as to what SOMAXCONN should be...).

Another argument _for_ including the patch in 2.6.0 is so that we
don't have to add a user-visible change in the middle of 2.6 (e.g.,
simplifies documentation etc).  Plus the patch is trivial.

  Andi> Another alternative would be to make it a fraction of the
  Andi> listen() argument per socket
  Andi> (e.g. min(tcp_max_syn_backlog,min(128,10%*listenarg))) to
  Andi> allow the application to easily change it.

I don't understand what purpose this would serve.  Seems to me it
would make life only more complicated for apps that know what they're
doing.

	--david