From owner-svn-src-projects@freebsd.org Wed Mar 2 15:53:09 2016 Return-Path: Delivered-To: svn-src-projects@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 667F2AC0C4B for ; Wed, 2 Mar 2016 15:53:09 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2DE31FFE; Wed, 2 Mar 2016 15:53:08 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 2 Mar 2016 16:51:55 +0100 Date: Wed, 2 Mar 2016 16:52:04 +0100 From: Marko Zec To: "Bjoern A. Zeeb" CC: , Subject: Re: svn commit: r296310 - projects/vnet/sys/netinet Message-ID: <20160302165204.0f0a43e6@x23> In-Reply-To: <201603021118.u22BII4Q076146@repo.freebsd.org> References: <201603021118.u22BII4Q076146@repo.freebsd.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [161.53.63.210] X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 15:53:09 -0000 On Wed, 2 Mar 2016 11:18:18 +0000 "Bjoern A. Zeeb" wrote: > Author: bz > Date: Wed Mar 2 11:18:17 2016 > New Revision: 296310 > URL: https://svnweb.freebsd.org/changeset/base/296310 > > Log: > It looks like as with the safety belt of DELAY(hz) fastened (*) we > can completely tear down and free all memory for TCP (after r281599). > > (*) in theory a few ticks should be good enough to make sure the > timers are all really gone. I wonder if we could use a better matric > here and check a tcbcb count as an optimization. ... > @@ -737,10 +737,18 @@ tcp_destroy(void *unused __unused) > { > int error; > > + /* > + * All our processes are gone, all our sockets should be > cleaned > + * up, which means, which should past the tcp_discardcb() > calls. > + * Sleep to let all tcpcb timers really disappear and then > cleanup. > + * Timewait will cleanup it's queue and will be ready to go. > + */ > + DELAY(hz); With kern.hz=1000 (default value) this will sleep for a single tick duration. With kern.hz=100 this will sleep less than a tick. Is this the intended behavior? > tcp_hc_destroy(); > syncache_destroy(); > tcp_tw_destroy(); > in_pcbinfo_destroy(&V_tcbinfo); > + /* tcp_discardcb() clears the sack_holes up. */ > uma_zdestroy(V_sack_hole_zone); > uma_zdestroy(V_tcpcb_zone); > > > Modified: projects/vnet/sys/netinet/tcp_timewait.c > ============================================================================== > --- projects/vnet/sys/netinet/tcp_timewait.c Wed Mar 2 > 10:23:50 2016 (r296309) +++ > projects/vnet/sys/netinet/tcp_timewait.c Wed Mar 2 11:18:17 > 2016 (r296310) @@ -186,7 +186,7 @@ tcp_tw_init(void) { > > V_tcptw_zone = uma_zcreate("tcptw", sizeof(struct tcptw), > - NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE); > + NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); > TUNABLE_INT_FETCH("net.inet.tcp.maxtcptw", &maxtcptw); > if (maxtcptw == 0) > uma_zone_set_max(V_tcptw_zone, tcptw_auto_size()); >