Thread (73 messages) 73 messages, 14 authors, 2005-03-31

Re: [Ksummit-2005-discuss] Summary of 2005 Kernel Summit Proposed Topics

From: Matt Mackall <hidden>
Date: 2005-03-29 17:03:32

Possibly related (same subject, not in this thread)

On Tue, Mar 29, 2005 at 05:11:59PM +0200, Andi Kleen wrote:
On Mon, Mar 28, 2005 at 11:24:55AM -0500, Rik van Riel wrote:
quoted
On Mon, 28 Mar 2005, Andi Kleen wrote:
quoted
So in short using mempools on receiving is not needed.
It is, because you have to ensure that the memory that's
needed to receive network packets isn't tied up receiving
packets for non-critical sockets, which would leave the
critical sockets deadlocked.
Again the in socket queue is in no way different from all
the tens of hundreds of limited size queues that make 
up a network. It is quite useless to concentrate on only
one queue in the receiver computer, while all the others still can lose 
packets.

The only way to solve such problems in the TCP/IP model
is to retransmit at the source. This means the TCP write
path needs to be reliable, but receiving does not need to be.
You don't seem to understand the deadlock yet. Host is OOM. Host must
flush pages to target to free memory. Host manages to draw skbs from
private reserve to do its writes. Target acknowledges writes, but host
is _still OOM_ and there is no memory including GFP_ATOMIC to allocate
receive buffers. Retransmission doesn't help because the
acknowledgements will always be dropped.

So it seems we need a way to receive such acknowledgements and quickly
discard everything else when we're pushed up against OOM.

-- 
Mathematics is the supreme nostalgia of our time.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help