On Tue, Aug 15, 2006 at 07:05:07PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:

quoted

quoted

So network allocator reserves above megabyte and works with it in a
smart way (without too much overhead).
Then system goes into OOM and requires to swap a page, which
notification was sent to remote swap storage.
Swap storage then sends an ack for that data, since network allocations
are separated from main system ones, network allocator easily gets 60
(or 4k, since it has a reserve, which exeeds maximum allowed TCP memory
limit) bytes for ack and process than notification thus "freeing" acked
data and main system can work with that free memory.
No need to detect OOM or something other - it just works.

I expect you will give me an example, when all above megabyte is going
to be stuck somewhere.
But... If it is not acked, each new packet goes slow path since VJ header 
prediction fails and falls into memory limit check which will drop that
packet immediately without event trying to select a socket.

I mean without trying to queue data into socket.

quoted

Not sure on the details; but you say: when we reach the threshold all
following packets will be dropped. So if you provide enough memory to
exceed the limit, you have some extra. If you then use that extra bit to
allow ACKs to pass through, then you're set.

Sounds good, but you'd have to carve a path for the ACKs, right? Or is
that already there?

Acks with or without attached data are processed before data queueing.
See tcp_rcv_established().

Just for clarification: we are talking about slow path above.

-- 
	Evgeniy Polyakov

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