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
<jchar...@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

_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to