Thread (128 messages) 128 messages, 16 authors, 2006-08-25

Re: [RFC][PATCH 2/9] deadlock prevention core

From: Peter Zijlstra <hidden>
Date: 2006-08-14 08:36:50
Also in: lkml, netdev

On Mon, 2006-08-14 at 12:25 +0400, Evgeniy Polyakov wrote:
On Mon, Aug 14, 2006 at 10:15:52AM +0200, Peter Zijlstra (a.p.zijlstra@chello.nl) wrote:
quoted
quoted
If this refers to the socket buffers, they're mostly allocated with
at least __GFP_WAIT, aren't they?
Wherever it is that packets go if the local end is tied up and cannot
accept them instantly. The simple but prob wrong calculation I made for
evgeniy is: suppose we have 64k sockets, each socket can buffer up to
128 packets, and each packet can be up to 16k (roundup for jumboframes)
large, that makes for 128G of memory. This calculation is wrong on
several points (we can have >64k sockets, and I have no idea on the 128)
but the order of things doesn't get better.
TCP memory is limited for all sockets - it is tcp_*mem parameters.
tcp_mem max on my amd64 with 1gb of ram is 768 kb for _all_ sockets.
Yes, I've said as much a few emails back, but that does not make the
theoretical limit any lower.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help