From: Eric Dumazet <dada1@cosmosbay.com>
To: Anton Blanchard <anton@samba.org>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] Limit size of route cache hash table
Date: Mon, 27 Apr 2009 08:12:21 +0200 [thread overview]
Message-ID: <49F54CC5.7020600@cosmosbay.com> (raw)
In-Reply-To: <20090427054702.GA15891@kryten>
Anton Blanchard a écrit :
>
> Hi,
>
>> Then boot with rhash_entries = 8000 ?
>> or
>> echo 1 >/proc/sys/net/ipv4/route/gc_interval
>
> Yes we are hardwiring it for now.
>
>> Sorry this limit is too small. Many of my customer machines would collapse.
>
> So what would a reasonable upper limit be? Surely we should cap it at some
> point?
>
A similar patch was done for the size of TCP hash table. It was something
like 512 * 1024 if I remember well. IMHO this same value would be fine for
IP route cache.
Yes, this was commit :
commit 0ccfe61803ad24f1c0fe5e1f5ce840ff0f3d9660
Author: Jean Delvare <jdelvare@suse.de>
Date: Tue Oct 30 00:59:25 2007 -0700
[TCP]: Saner thash_entries default with much memory.
On systems with a very large amount of memory, the heuristics in
alloc_large_system_hash() result in a very large TCP established hash
table: 16 millions of entries for a 128 GB ia64 system. This makes
reading from /proc/net/tcp pretty slow (well over a second) and as a
result netstat is slow on these machines. I know that /proc/net/tcp is
deprecated in favor of tcp_diag, however at the moment netstat only
knows of the former.
I am skeptical that such a large TCP established hash is often needed.
Just because a system has a lot of memory doesn't imply that it will
have several millions of concurrent TCP connections. Thus I believe
that we should put an arbitrary high limit to the size of the TCP
established hash by default. Users who really need a bigger hash can
always use the thash_entries boot parameter to get more.
I propose 2 millions of entries as the arbitrary high limit. This
makes /proc/net/tcp reasonably fast on the system in question (0.2 s)
while being still large enough for me to be confident that network
performance won't suffer.
This is just one way to limit the hash size, there are others; I am not
familiar enough with the TCP code to decide which is best. Thus, I
would welcome the proposals of alternatives.
[ 2 million is still too large, thus I've modified the limit in the
change to be '512 * 1024'. -DaveM ]
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Thanks
next prev parent reply other threads:[~2009-04-27 6:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 3:04 [PATCH] Limit size of route cache hash table Anton Blanchard
2009-04-27 5:17 ` Eric Dumazet
2009-04-27 5:47 ` Anton Blanchard
2009-04-27 6:12 ` Eric Dumazet [this message]
2009-04-27 6:36 ` David Miller
2009-04-27 6:47 ` Eric Dumazet
2009-04-27 11:44 ` Anton Blanchard
2009-04-27 11:50 ` Anton Blanchard
2009-04-27 12:40 ` David Miller
2009-04-27 6:35 ` David Miller
2009-04-27 6:11 ` David Miller
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=49F54CC5.7020600@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=anton@samba.org \
--cc=netdev@vger.kernel.org \
/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).