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

[Matt Mackall <mpm@selenic.com>]

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:
> > On Mon, 28 Mar 2005, Andi Kleen wrote:
> > 
> > > 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.