netdev - Re: [PATCH] net: Saner thash_entries default with much memory

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: <20071030.005758.184980120.davem@davemloft.net>
Date:	Tue, 30 Oct 2007 00:57:58 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ak@...e.de
Cc:	jdelvare@...e.de, netdev@...r.kernel.org
Subject: Re: [PATCH] net: Saner thash_entries default with much memory

From: Andi Kleen <ak@...e.de>
Date: Fri, 26 Oct 2007 17:34:17 +0200

> On Fri, Oct 26, 2007 at 05:21:31PM +0200, Jean Delvare wrote:
> > I propose 2 millions of entries as the arbitrary high limit. This
> 
> It's probably still far too large.

I agree.  Perhaps a better number is something on the order of
(512 * 1024) so I think I'll check in a variant of Jean's patch
with just the limit decreased like that.

Using just some back of the envelope calculations, on UP 64-bit
systems each socket uses about 2424 bytes minimum of memory (this is
the sum of tcp_sock, inode, dentry, socket, and file on sparc64 UP).
This is an underestimate because it does not even consider things like
allocator overhead.

Next, machines that service that many sockets typically have them
mostly with full transmit queues talking to a very slow receiver at
the other end.  So let's estimate that on average each socket consumes
about 64K of retransmit queue data.

I think this is an extremely conservative estimate beause it doesn't
even consider overhead coming from struct sk_buff and related state.

So for (512 * 1024) of established sockets we consume roughly 35GB of
memory, this is '((2424 + (64 * 1024)) * (512 * 1024))'.

So to me (512 * 1024) is a very reasonable limit and (with lockdep
and spinlock debugging disabled) this makes the EHASH table consume
8MB on UP 64-bit and ~12MB on SMP 64-bit systems.

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