Kernel Bug Tracker – Bug 16254
TCP stream performance regression due to c377411f2494a931ff7facdbb3a6839b1266bcf6
Last modified: 2010-07-09 22:59:21 UTC
Subject : TCP stream performance regression due to c377411f2494a931ff7facdbb3a6839b1266bcf6
Submitter : "Alex,Shi" <email@example.com>
Date : 2010-06-18 7:17
Message-ID : 1276845448.2118.346.camel@debian
References : http://marc.info/?l=linux-kernel&m=127684931020672&w=2
This entry is being used for tracking a regression from 2.6.33. Please don't
close it until the problem is fixed in the mainline.
Author: Eric Dumazet <firstname.lastname@example.org>
Date: Tue, 27 Apr 2010 22:13:20 +0000 (15:13 -0700)
net: sk_add_backlog() take rmem_alloc into account
Current socket backlog limit is not enough to really stop DDOS attacks,
because user thread spend many time to process a full backlog each
round, and user might crazy spin on socket lock.
We should add backlog size and receive_queue size (aka rmem_alloc) to
pace writers, and let user run without being slow down too much.
Introduce a sk_rcvqueues_full() helper, to avoid taking socket lock in
Under huge stress from a multiqueue/RPS enabled NIC, a single flow udp
receiver can now process ~200.000 pps (instead of ~100 pps before the
patch) on a 8 core machine.
Signed-off-by: Eric Dumazet <email@example.com>
Signed-off-by: David S. Miller <firstname.lastname@example.org>
First-Bad-Commit : c377411f2494a931ff7facdbb3a6839b1266bcf6