On Sat, Aug 12, 2006 at 10:40:23AM -0400, Rik van Riel ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > >On Sat, Aug 12, 2006 at 11:19:49AM +0200, Peter Zijlstra > >([EMAIL PROTECTED]) wrote: > >>>As you described above, memory for each packet must be allocated (either > >>>from SLAB or from reserve), so network needs special allocator in OOM > >>>condition, and that allocator should be separated from SLAB's one which > >>>got OOM, so my purpose is just to use that different allocator (with > >>>additional features) for netroking always. > > > >No it is not. There are socket queues and they are limited. Things like > >TCP behave even better. > > Ahhh, but there are two allocators in play here. > > The first one allocates the memory for receiving packets. > This can be one pool, as long as it is isolated from > other things in the system it is fine. > > The second allocator allocates more memory for socket > buffers. The memory critical sockets should get their > memory from a mempool, once normal socket memory > allocations start failing. > > This means our allocation differentiation only needs > to happen at the socket stage. > > Or am I overlooking something?
Yep. Socket allocations end up with alloc_skb() which is essentialy the same as what is being done for receiving path skbs. If you really want to separate critical from non-critical sockets, it is much better not to play with alloc_skb() but directly forbid it in appropriate socket allocation function like sock_alloc_send_skb(). What I suggested in previous e-mail is to separate networking allocations from other system allocations, so problem in main allocator and it's OOM would never affect network path. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html