From owner-freebsd-current@FreeBSD.ORG Thu Jan 15 15:58:12 2015 Return-Path: Delivered-To: freebsd-current@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 62A65B6E; Thu, 15 Jan 2015 15:58:12 +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 1444A68E; Thu, 15 Jan 2015 15:58:12 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YBmoE-00034s-4N; Thu, 15 Jan 2015 18:58:10 +0300 Date: Thu, 15 Jan 2015 18:58:10 +0300 From: Slawa Olhovchenkov To: Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress Message-ID: <20150115155810.GE3698@zxy.spb.ru> References: <54A92ED1.2070906@selasky.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B7E1E4.6040906@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 , Jason Wolfe , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 15:58:12 -0000 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).