netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).