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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2005-03-28 at 18:12 +0200, Andi Kleen wrote:
> This does not work because mempools assume you can sleep,
> and in most NIC drivers you cant while doing RX refill.
> The NIC drivers can be rewritten to do this refilling in
> a workqueue. But it is not clear it is useful anyways because
> Linux failing to allocate a buffer is no different from
> the network overflowing the hardware queue of the network
> device, which Linux cannot do anything about. 

Actually, not in 2.6 ... we had the same issue in SCSI using mempools
for sglist allocation.  All of the mempool alocation paths now take gfp_
flags, so you can specify GFP_ATOMIC for interrupt context.

> Basically a network consists of lots of interconnected
> queues, and even if you try to make the Linux specific
> side of the queue reliable there are lots of other queues
> that can still lose packets.
> 
> With TCP that is no problem of course because in case of 
> a packet loss the packet is just retransmitted. 
> 
> So in short using mempools on receiving is not needed.

The object isn't to make the queues *reliable* it's to ensure the system
can make forward progress.  So all we're trying to ensure is that the
sockets used to service storage have some probability of being able to
send and receive packets during low memory.

In your scenario, if we're out of memory and the system needs several
ACK's to the swap device for pages to be released to the system, I don't
see how we make forward progress since without a reserved resource to
allocate from how does the ack make it up the stack to the storage
driver layer?

James