From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 16:41:50 2015 Return-Path: Delivered-To: freebsd-arch@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 C91FA98C; Thu, 15 Jan 2015 16:41:50 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (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 8294CC70; Thu, 15 Jan 2015 16:41:50 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8619C1FE022; Thu, 15 Jan 2015 17:41:48 +0100 (CET) Message-ID: <54B7EDFC.9020406@selasky.org> Date: Thu, 15 Jan 2015 17:42:36 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Slawa Olhovchenkov Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress 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> <20150115155810.GE3698@zxy.spb.ru> In-Reply-To: <20150115155810.GE3698@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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:41:50 -0000 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. --HPS