netdev - Re: [PATCH] Limit size of route cache hash table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49F54CC5.7020600@cosmosbay.com>
Date:	Mon, 27 Apr 2009 08:12:21 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Anton Blanchard <anton@...ba.org>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH] Limit size of route cache hash table

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@...e.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@...e.de>
    Signed-off-by: David S. Miller <davem@...emloft.net>



Thanks

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html