TCP stack lock contention with short-lived connections

[Julien Charbon]

 Hi,

On 03/10/14 15:16, Julien Charbon wrote:
> On 23/05/14 14:06, Julien Charbon wrote:
>> On 27/02/14 11:32, Julien Charbon wrote:
>>> On 07/11/13 14:55, Julien Charbon wrote:
>>>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
>>>> <jcharbon at verisign.com> wrote:
>>>>> I have put technical and how-to-repeat details in below PR:
>>>>>
>>>>> kern/183659: TCP stack lock contention with short-lived connections
>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659
>>>>>
>>>>>   We are currently working on this performance improvement effort;  it
>>>>> will impact only the TCP locking strategy not the TCP stack logic
>>>>> itself.  We will share on freebsd-net the patches we made for
>>>>> reviewing and improvement propositions;  anyway this change might also
>>>>> require enough eyeballs to avoid tricky race conditions introduction
>>>>> in TCP stack.

 As usual, a follow-up the TCP short-lived connections performance
improvement progress:

 Thanks to jhb (mentor/reviewer) and adrian, rpaulo, rwatson
(reviewers), two related commits have been added in HEAD:

 - First, just a fix for a wrong ECONNRESET error on close():

A connection in TIME_WAIT state before calling close() actually did not
received any RST packet
https://svnweb.freebsd.org/base?view=revision&revision=273014

 - Second, a race condition fix with a code clean-up:

Fix a race condition in TCP timewait between tcp_tw_2msl_reuse() and
tcp_tw_2msl_scan()
https://svnweb.freebsd.org/base?view=revision&revision=273850

 It means that the whole set of tcp_tw_2msl_scan()-related changes could
now be MFC-ed in 10-STABLE as the KBI stability can be kept now:

https://svnweb.freebsd.org/base?view=revision&revision=264321
https://svnweb.freebsd.org/base?view=revision&revision=264342
https://svnweb.freebsd.org/base?view=revision&revision=264351
https://svnweb.freebsd.org/base?view=revision&revision=264356
https://svnweb.freebsd.org/base?view=revision&revision=273850

 It also means that only one (big) related patch remains to be pushed:

Introduce the INP_LIST global mutex for protecting pcbinfo
global structures.  Then use INP_INFO_RLOCK in critical paths to
increase TCP processing scalability, and use INP_INFO_WLOCK in full INPs
iteration loops.  (See also joined patch).
https://github.com/verisign/freebsd/commit/6e47f726f4d58f986e977fb0f816b8a271804460

 Nothing new here, just check previous emails in this thread to get all
details.  So far, we are adding comments and reviewing the change in
more specific cases, then we plan to push this change in review around
December 2014.

 My 2 cents.

--
Julien

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 536 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20141103/2979f441/attachment.sig>