From owner-freebsd-stable@FreeBSD.ORG Tue Dec 21 08:59:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BD90106564A for ; Tue, 21 Dec 2010 08:59:52 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 73CF48FC0A for ; Tue, 21 Dec 2010 08:59:51 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA01390; Tue, 21 Dec 2010 10:59:43 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PUy4N-000KzQ-F9; Tue, 21 Dec 2010 10:59:43 +0200 Message-ID: <4D106C7F.5090409@freebsd.org> Date: Tue, 21 Dec 2010 10:59:43 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4cfc72a5.3nAjkv8mdrO/NrKQ%perryh@pluto.rain.com> <4CFD0633.9060509@freebsd.org> <4d089a74.vwMJkPEIddt7PIxy%perryh@pluto.rain.com> <4D08AACB.6060306@freebsd.org> <4d09dd2e.iVncbZ/gHBXX0WdL%perryh@pluto.rain.com> <4D09E0F3.5040302@freebsd.org> <4d0dcc58.Z6ITxDmhSuMVmGVR%perryh@pluto.rain.com> In-Reply-To: <4d0dcc58.Z6ITxDmhSuMVmGVR%perryh@pluto.rain.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Tunables (Re: How to debug a double fault? (Re: Could MSGBUF_SIZE be made a loader tunable?)) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2010 08:59:52 -0000 on 19/12/2010 11:11 perryh@pluto.rain.com said the following: > Andriy Gapon wrote: >> on 16/12/2010 11:34 perryh@pluto.rain.com said the following: >>> Andriy Gapon wrote: >>>> BTW, are you sure that you correctly placed initialization of >>>> msgbufsize ? >>> >>> I am not at all sure of that ... >>> >>> Apart from the name, msgbufsize is set up in exactly the same >>> way and place -- in init_param1() -- as maxswzone and maxbcache. >>> Perhaps that is not early enough ... >> >> I don't see any connection between msgbufsize and maxswzone, >> so I also don't know if that place is early enough. > > The only "connection" is that maxswzone and maxbcache seemed to > be loader tunables that cannot be changed (via sysctl) while the > system is running -- the same usage paradigm I have in mind for > msgbufsize. In other words they are all tunables. We have dozens of them. > I've since found the description of i386 startup in the Architecture > Handbook, and based on that -- and the code in locore.s and machdep.c > -- it certainly _seems_ as if init_param1() should be early enough: > > Practically the first thing that locore.s does after establishing > virtual addressing is to call init386(), and init386() calls > init_param1() long before it either accesses msgbufsize directly > or calls getmemsize() (which uses msgbufsize to allocate space for > the kernel message buffer). Documentation and code are known to get out of sync sometimes. Not saying that this is the case here though... >> Just try to initialize the variable where it's defined and use >> TUNABLE_LONG. > > Is there any documentation on how to use the TUNABLE_* macros, or > on when to use, say, TUNABLE_LONG vs TUNABLE_LONG_FETCH? I found > nothing with their definitions in sys/kernel.h, nor in any of the > base-system manpages, nor in /usr/share/doc/... Another question for which I don't have an answer. So far in my experience TUNABLE_XXX has always sufficed for me, I've never had a reason to use TUNABLE_XXX_FETCH. Technical difference is that TUNABLE_XXX_FETCH is a function (function-like macro) that explicitly fetches tunable's value from kernel environment; while TUNABLE_XXX is a wrapper around SYSINIT that registers the tunable for automatic processing during rather early stage of boot (SI_SUB_TUNABLES). -- Andriy Gapon