From: "David S. Miller" <davem@davemloft.net>
To: Christian Schmid <webmaster@rapidforum.com>
Cc: netdev@oss.sgi.com
Subject: Re: Bug-hunting
Date: Tue, 22 Feb 2005 11:51:14 -0800 [thread overview]
Message-ID: <20050222115114.0d0e568e.davem@davemloft.net> (raw)
In-Reply-To: <421B8563.9030608@rapidforum.com>
On Tue, 22 Feb 2005 20:17:55 +0100
Christian Schmid <webmaster@rapidforum.com> wrote:
> No. This is a new thing and this wasnt there before. In 2.6.10-rc2 the kernel aborted programs with
> "Out of memory" when too many buffers are allocated and low memory was full. NOW it just shrinks the
> buffers dynamically. I don't want that. I have a 2/2 system and I want 1600 MB for buffers but you
> only allow around 700 MB for buffers. This is definetly NEW.
It always shrinks the TCP socket buffer usage when the total socket
memory used by TCP is over the threshold. This code has been there
for 3 years at least.
If the behavior has changed, that's interesting and probably due to
some other change. It could even be a MM layer change that is causing
things to behave differently now for you, and because things are
being tweaked in the memory management all the time (particularly
the handling of lowmem vs. highmem) this would not surprise me at
all.
But the basic framework for shrinking socket buffers when total TCP
memory usage crosses some threshold has been there and has been
enabled for a long time.
Anyways, we're stalled on figuring out exactly what is wrong due to
lack of information and difficulty in reproducing. The ball is still
in your court.
Why don't you put together a very simple test case that others can
use to analyze and reproduce your bug? I bet we'll fix it or figure
out what is wrong with your app within 24 hours once you do that. :-)
next prev parent reply other threads:[~2005-02-22 19:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-22 15:07 Bug-hunting Christian Schmid
2005-02-22 18:44 ` Bug-hunting David S. Miller
2005-02-22 19:17 ` Bug-hunting Christian Schmid
2005-02-22 19:51 ` David S. Miller [this message]
2005-02-22 23:21 ` Bug-hunting Christian Schmid
2005-02-23 3:30 ` Bug-hunting David S. Miller
2005-02-23 10:28 ` Bug-hunting Christian Schmid
2005-02-23 19:29 ` Bug-hunting David S. Miller
2005-02-23 19:41 ` Bug-hunting Christian Schmid
2005-02-23 19:53 ` Bug-hunting David S. Miller
2005-02-23 19:46 ` Bug-hunting Christian Schmid
2005-02-23 20:00 ` Bug-hunting John Heffner
2005-02-24 12:29 ` Bug-hunting Christian Schmid
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050222115114.0d0e568e.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=netdev@oss.sgi.com \
--cc=webmaster@rapidforum.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).