Re: [RFC][PATCH 2/9] deadlock prevention core

[Daniel Phillips <phillips@google.com>]

Andrew Morton wrote:
> What is a "socket wait queue" and how/why can it consume so much memory?

Two things:

   1) sk_buffs in flight between device receive interrupt and layer 3
      protocol/socket identification.

   2) sk_buffs queued onto a particular socket waiting for some task to
      come along and pull them off via read or equivalent.

Case (1) probably can't consume a unbounded amount of memory, but I
would not swear to that with my current reading knowledge of the network
stack.  The upper bound here is obscured by clever SMP device processing,
netfilter options, softirq scheduling questions, probably other things.
This needs a considered explanation from a network guru, or perhaps a
pointer to documentation.

Case (2) is the elephant under the rug.  Some form of TCP memory
throttling exists, but there is no organized way to correlate that with
actual memory conditions, and it appears to be exposed to user control.
Memory throttling seems to be entirely absent for non-TCP protocols,
e.g., UDP.

> Can it be prevented from doing that?

This patch set does that, and also provides an emergency reserve for
network devices in order to prevent atomic allocation failures while
trying to refill NIC DMA buffer rings.  It is the moral equivalent of
our bio reservation scheme, but with additional twists specific to the
network stack.

Regards,

Daniel

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