From owner-freebsd-net@FreeBSD.ORG Tue Nov 4 03:56:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8514743B for ; Tue, 4 Nov 2014 03:56:42 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5725D92D for ; Tue, 4 Nov 2014 03:56:42 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id r10so12817670pdi.17 for ; Mon, 03 Nov 2014 19:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uFCsMATL4ubvkIEw3sHp3H+FHNGI7O1n0J4JN5ZeqtE=; b=aYPOnsLQNZTM0n/76dpYYDICrgLtgPdHZisa8kVaSPbx01DHdfgflVujrd0yqdN0pw u8CTzEEnDLe2txwOm0W0SxlBB/62CTeipPt9SKeNR59Z4ZF5RI/PwNhYGFpwoIcZCn/R 4ROVpGBQkaUbUlcA40JD7cAMQJ6Fm5eIzMBixJx69W2qKOQakHbZseuHYkHOvVufbIyS steQ3cHtKHlJvpJ0W7CmL5pRmqQdX6lZ5H7eXrvPPWB+P05LGUw4Yzve72Ml9KIXrj8n TjtIu6UysO7T1AlIuNKvo4sGYRPZglkMIaTlMSK1S7BaQWXVDJQXVObKkfd0tQ5Br8/u CsIw== X-Received: by 10.68.65.68 with SMTP id v4mr42002380pbs.52.1415073383344; Mon, 03 Nov 2014 19:56:23 -0800 (PST) Received: from kmatoMacBook-Pro.local ([221.234.44.207]) by mx.google.com with ESMTPSA id hp4sm18419141pbb.95.2014.11.03.19.56.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Nov 2014 19:56:22 -0800 (PST) Message-ID: <54584E61.3020605@gmail.com> Date: Tue, 04 Nov 2014 11:56:17 +0800 From: k simon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: TCP stack lock contention with short-lived connections References: <537F39DF.1090900@verisign.com> <542EA1C9.6080907@freebsd.org> <5457832D.6070709@freebsd.org> In-Reply-To: <5457832D.6070709@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 03:56:42 -0000 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 >>>>> 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 >