Hi David, Le mardi 30 octobre 2007, David Miller a écrit : > From: Andi Kleen <[EMAIL PROTECTED]> > 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.
That's very fine with me. I originally proposed an admittedly high limit value to increase the chance to see it accepted. I am not familiar enough with networking to know what a more reasonable limit would be, so I'm leaving it to the experts. > 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. OK, let's go with (512 * 1024) then. Want me to send an updated patch? Thanks, -- Jean Delvare Suse L3 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
