tipc: eliminate aggregate sk_receive_queue limit
authorYing Xue <ying.xue@windriver.com>
Tue, 27 Nov 2012 11:15:27 +0000 (06:15 -0500)
committerPaul Gortmaker <paul.gortmaker@windriver.com>
Fri, 7 Dec 2012 19:19:52 +0000 (14:19 -0500)
commit9da3d475874f4da49057767913af95ce01063ba3
tree36397ebac269552b2c1223fb64740a4aab49474a
parentc008413850d1d48cc02c940280bf2dcf76160f4c
tipc: eliminate aggregate sk_receive_queue limit

As a complement to the per-socket sk_recv_queue limit, TIPC keeps a
global atomic counter for the sum of sk_recv_queue sizes across all
tipc sockets. When incremented, the counter is compared to an upper
threshold value, and if this is reached, the message is rejected
with error code TIPC_OVERLOAD.

This check was originally meant to protect the node against
buffer exhaustion and general CPU overload. However, all experience
indicates that the feature not only is redundant on Linux, but even
harmful. Users run into the limit very often, causing disturbances
for their applications, while removing it seems to have no negative
effects at all. We have also seen that overall performance is
boosted significantly when this bottleneck is removed.

Furthermore, we don't see any other network protocols maintaining
such a mechanism, something strengthening our conviction that this
control can be eliminated.

As a result, the atomic variable tipc_queue_size is now unused
and so it can be deleted.  There is a getsockopt call that used
to allow reading it; we retain that but just return zero for
maximum compatibility.

Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
[PG: phase out tipc_queue_size as pointed out by Neil Horman]
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
net/tipc/socket.c