On Sat, Aug 12, 2006 at 10:56:31AM -0400, Rik van Riel ([email protected]) wrote:
> >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().
>
> The problem is the RECEIVE side.
>
> >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.
>
> That solves half of the problem. We still need to make sure we
> do not allocate memory to non-critical sockets when the system
> is almost out of memory.
One must receive a packet to determine if that packet must be dropped
until tricky hardware with header split capabilities or MMIO copying is
used. Peter uses special pool to get data from when system is in OOM (at
least in his latest patchset), so allocations are separated and thus
network code is not affected by OOM condition, which allows to make
forward progress.
Critical flag can be setup through setsockopt() and checked in
tcp_v4_rcv().
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
