From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 16:48:04 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D36DACD9; Thu, 15 Jan 2015 16:48:04 +0000 (UTC) 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 87E78CE9; Thu, 15 Jan 2015 16:48:04 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YBnaS-0003wC-Ph; Thu, 15 Jan 2015 19:48:00 +0300 Date: Thu, 15 Jan 2015 19:48:00 +0300 From: Slawa Olhovchenkov To: Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress Message-ID: <20150115164800.GF3698@zxy.spb.ru> References: <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <20150115154617.GB10325@zxy.spb.ru> <54B7E1E4.6040906@selasky.org> <20150115155810.GE3698@zxy.spb.ru> <54B7EDFC.9020406@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B7EDFC.9020406@selasky.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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 Cc: Adrian Chadd , FreeBSD Current , sbruno@freebsd.org, Jason Wolfe , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 16:48:04 -0000 On Thu, Jan 15, 2015 at 05:42:36PM +0100, Hans Petter Selasky wrote: > On 01/15/15 16:58, Slawa Olhovchenkov wrote: > > On Thu, Jan 15, 2015 at 04:51:00PM +0100, Hans Petter Selasky wrote: > > > >> On 01/15/15 16:46, Slawa Olhovchenkov wrote: > >>> On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote: > >>> > >>> Only stability impovement? > >>> Or performance too? > >> > >> Hi, > >> > >> Stability improvement mostly. Should not affect performance from what I > >> know. Some changes are made about when and how we can select a different > >> callback CPU for a callout callback. Try reading the updated timeout(9) > > > > I am not kernel guru and can't be draw a conclusion from manual page. > > > >> man manual page first. Maybe it answers your question. Else feel free to > >> ask here. > > > > As I understand performance for massive TCP connections (tens of > > thousands connections) will be same, no improvement, no degraded? > > (very high lock congestion on TCP timers working). > > Hi, > > There is no difference in memory footprint per TCP connection. > > There is no significant different in the amount of code executed when a > callout is started/stopped or reset. > > There might be a reduction in the number of times the spinlocks inside > the callout subsystem are locked/unlocked, due to some simplifications > made and checks for redundant locking. > > The changes are mainly about closing some races in the callout subsystem > and cornercases towards the TCP/IP stack which use callouts. > > There is a patch for the TCP/IP stack coming possibly next week to take > advantage of the new callout_drain_async() function. It is not ready > yet, and I'm waiting for the current callout patch to settle first. Thanks. I am going to try this patch in 10-STABLE branch.