On Sat, Aug 12, 2006 at 10:40:23AM -0400, Rik van Riel (riel@xxxxxxxxxx) wrote:Evgeniy Polyakov wrote:On Sat, Aug 12, 2006 at 11:19:49AM +0200, Peter Zijlstra (a.p.zijlstra@xxxxxxxxx) wrote:Ahhh, but there are two allocators in play here.No it is not. There are socket queues and they are limited. Things likeAs you described above, memory for each packet must be allocated (either>from SLAB or from reserve), so network needs special allocator in OOMcondition, 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.
TCP behave even better.
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.