Re: Network vm deadlock... solution?

["Martin J. Bligh" <mbligh@mbligh.org>]

--Francois Romieu <romieu@fr.zoreil.com> wrote (on Tuesday, August 02, 2005 23:43:40 +0200):

> Daniel Phillips <phillips@istop.com> :
> [...]
>> A point on memory pressure: here, we are not talking about the continuous 
>> state of running under heavy load, but rather the microscopically short 
>> periods where not a single page of memory is available to normal tasks.  It 
>> is when a block IO event happens to land inside one of those microscopically 
>> short periods that we run into problems.
> 
> You suggested in a previous message to use an emergency allocation pool at
> the driver level. Afaik, 1) the usual network driver can already buffer a
> bit with its Rx descriptor ring and 2) it more or less tries to refill it
> each time napi issues its ->poll() method. So it makes me wonder:
> - have you collected evidence that the drivers actually run out of memory
>   in the (microscopical) situation you describe ?

There's other situations where it does (ie swap device dies, etc).

> - instead of modifying each and every driver to be vm aware, why don't
>   you hook in net_rx_action() when memory starts to be low ?
> 
> Btw I do not get what the mempool/GFP_CRITICAL idea buys: it seems redundant
> with the threshold ("if (memory_pressure)") used in the Rx path to decide
> that memory is low.

It's send-side, not receive.

M.

--
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>