From owner-freebsd-stable@freebsd.org Wed Sep 21 19:51:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17C29BE4696 for ; Wed, 21 Sep 2016 19:51:59 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC3A1DC3; Wed, 21 Sep 2016 19:51:58 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1bmnYh-000Mcq-Mz; Wed, 21 Sep 2016 22:51:55 +0300 Date: Wed, 21 Sep 2016 22:51:55 +0300 From: Slawa Olhovchenkov To: Julien Charbon Cc: Konstantin Belousov , freebsd-stable@FreeBSD.org, hiren panchasara Subject: Re: 11.0 stuck on high network load Message-ID: <20160921195155.GW2840@zxy.spb.ru> References: <20160915085938.GN38409@kib.kiev.ua> <20160915090633.GS2840@zxy.spb.ru> <20160916181839.GC2960@zxy.spb.ru> <20160916183053.GL9397@strugglingcoder.info> <20160916190330.GG2840@zxy.spb.ru> <78cbcdc9-f565-1046-c157-2ddd8fcccc62@freebsd.org> <20160919204328.GN2840@zxy.spb.ru> <8ba75d6e-4f01-895e-0aed-53c6c6692cb9@freebsd.org> <20160920202633.GQ2840@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 19:51:59 -0000 On Wed, Sep 21, 2016 at 09:11:24AM +0200, Julien Charbon wrote: > > You can also use Dtrace and lockstat (especially with the lockstat -s > option): > > https://wiki.freebsd.org/DTrace/One-Liners#Kernel_Locks > https://www.freebsd.org/cgi/man.cgi?query=lockstat&manpath=FreeBSD+11.0-RELEASE > > But I am less familiar with Dtrace/lockstat tools. I am still use old kernel and got lockdown again. Try using lockstat (I am save more output), interesting may be next: R/W writer spin on writer: 190019 events in 1.070 seconds (177571 events/sec) ------------------------------------------------------------------------------- Count indv cuml rcnt nsec Lock Caller 140839 74% 74% 0.00 24659 tcpinp tcp_tw_2msl_scan+0xc6 nsec ------ Time Distribution ------ count Stack 4096 | 913 tcp_twstart+0xa3 8192 |@@@@@@@@@@@@ 58191 tcp_do_segment+0x201f 16384 |@@@@@@ 29594 tcp_input+0xe1c 32768 |@@@@ 23447 ip_input+0x15f 65536 |@@@ 16197 131072 |@ 8674 262144 | 3358 524288 | 456 1048576 | 9 ------------------------------------------------------------------------------- Count indv cuml rcnt nsec Lock Caller 49180 26% 100% 0.00 15929 tcpinp tcp_tw_2msl_scan+0xc6 nsec ------ Time Distribution ------ count Stack 4096 | 157 pfslowtimo+0x54 8192 |@@@@@@@@@@@@@@@ 24796 softclock_call_cc+0x179 16384 |@@@@@@ 11223 softclock+0x44 32768 |@@@@ 7426 intr_event_execute_handlers+0x95 65536 |@@ 3918 131072 | 1363 262144 | 278 524288 | 19 ------------------------------------------------------------------------------- > >> #1. Try above kernel options at least once, and see what you can get. > > > > OK, I am try this after some time. > > > >> #2. If #1 is a total failure try below patch: It won't solve anything, > >> it just makes tcp_tw_2msl_scan() less greedy when there is contention on > >> the INP write lock. If it makes the debugging more feasible, continue > >> to #3. > > > > OK, thanks. > > What purpose to not skip locked tcptw in this loop? > > If I understand your question correctly: According to your pmcstat > result, tcp_tw_2msl_scan() currently struggles with a write lock > (__rw_wlock_hard) and the only write lock used tcp_tw_2msl_scan() is > INP_WLOCK. No sign of contention on TW_RLOCK(V_tw_lock) currently. > > 51.86% [2413083] lock_delay @ /boot/kernel.VSTREAM/kernel > 100.0% [2413083] __rw_wlock_hard > 100.0% [2413083] tcp_tw_2msl_scan > > -- > Julien