TCP stack lock contention with short-lived connections

[k simon]

Great job. It would help me a lot.


Simon

在 14/11/3 21:29, 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
>