From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 16:23:12 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3779ECAE; Mon, 14 Jan 2013 16:23:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by mx1.freebsd.org (Postfix) with ESMTP id AB42D2D9; Mon, 14 Jan 2013 16:23:10 +0000 (UTC) Received: by mail-bk0-f41.google.com with SMTP id jg9so2111134bkc.0 for ; Mon, 14 Jan 2013 08:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MJwK5QiJyaS9fWNMo/yaZFKa7uX/AO53ObUmDIIqHjw=; b=o5YdDbyo1DzArLT9o9PtYVdpCS+nZf8T4NlsRxoj1HKLt/dStMr0R9eiFJHplK0Uh4 a3rYEGMfBqYsagPGJaEizOAWvm36w86dVWXoXeUkbT1v5mvFOsBH3mL03ohvv9qwojyG NmquN4JKxoPuMNjy1c+fkX3pKzDGOC7iKv1vqviTtWSwZ9pl5xEum3SaD+ljKO8RtNkg uufj1s+94QEAKrKf9UTajaMuDGsXXvWRDdfjIE5Pk57GtCTSnnDlpI76xA/mfBYhbeet U/djTpAIBEsm48M+ymkL03gaYaZggwM8KpxEu0m0B10pqWNrHwfy97e9na5ukQEAF8ep UjrQ== X-Received: by 10.204.3.206 with SMTP id 14mr39244118bko.120.1358180583687; Mon, 14 Jan 2013 08:23:03 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id e22sm10318424bke.14.2013.01.14.08.23.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 08:23:02 -0800 (PST) Sender: Alexander Motin Message-ID: <50F430E3.70501@FreeBSD.org> Date: Mon, 14 Jan 2013 18:22:59 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> <50C3AF72.4010902@rice.edu> <330405A1-312A-45A5-BB86-4969478D8BBD@bluezbox.com> <50D03E83.8060908@rice.edu> <50DD081E.8000409@bluezbox.com> <50EB1841.5030006@bluezbox.com> <50EB22D2.6090103@rice.edu> <50EB415F.8020405@freebsd.org> <50F04FE5.7010406@rice.edu> <50F1BD69.4060104@mu.org> <50F2F79C.7040109@mu.org> <50F41F8C.5030900@freebsd.org> <50F4297F.8050708@FreeBSD.org> <50F42CD7.6020400@freebsd.org> In-Reply-To: <50F42CD7.6020400@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Jan 2013 18:15:09 +0000 Cc: Adrian Chadd , src-committers@freebsd.org, Alan Cox , "Jayachandran C." , svn-src-all@freebsd.org, Alfred Perlstein , Oleksandr Tymoshenko , freebsd-arch@freebsd.org, svn-src-head@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:23:12 -0000 On 14.01.2013 18:05, Andre Oppermann wrote: > On 14.01.2013 16:51, Alexander Motin wrote: >> As I've actually written, there are two different things: >> ncallout -- number of preallocated callout structures for purposes of >> timeout() calls. That is a legacy API that is probably not very much >> used now, so that value don't need to be too big. But that allocation is >> static and if it will ever be exhausted system will panic. That is why >> it was set quite high. The right way now would be to analyze where that >> API is still used and estimate the really required number. > > Can timeout() be emulated on top of another API so we can do away with it? It is already emulated on top of callout_init()/callout_reset(). The problem is that callout_init()/callout_reset() assume storage memory to be allocated by consumer, while timeout() assumes it to be allocated by subsystem. The only way to solve it is to rewrite remaining timeout() consumers to use callout_init()/callout_reset() API directly. >> callwheelsize -- number of slots in the callwheel. That is purely >> optimizational value. If set too low, it will just increase number of >> hash collisions without effects other then some slowdown. Optimal value >> here does depend on number of callouts in system, but not only. Since >> array index there is not really a hash, it is practically useless to set >> array size it higher then median callout interval divided by hz (or by >> 1ms in calloutng). The problem is to estimate that median value, that >> completely depends on workload. > > OK. So for example a large number of TCP connection would use up a > large number of slots in the callwheel. I'll try to come up with a > reasonable sane scaling value. Yes, it _may_ use, but that also depends on time intervals. If most of these TCP timeouts will be few seconds long for ACK timeout, there will be no any performance difference between having callwheelsize of 100*hz and 10000*hz. Same time, if periods are measured in hours, like for keep-alives, increasing callwheelsize may be effective. >> Each one ncallout cost 32-52 bytes, while one callwheelsize only 8-16 >> and could probably be reduced to 4-8 by replacing TAILQ with LIST. So >> that is ncallout and respective timeout() API what should be managed in >> first order. > > I'll give it a try. Thanks. -- Alexander Motin