From owner-svn-src-all@FreeBSD.ORG Wed Oct 27 16:22:41 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54DB7106566B; Wed, 27 Oct 2010 16:22:41 +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 5CA7D8FC17; Wed, 27 Oct 2010 16:22:39 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA26207; Wed, 27 Oct 2010 19:22:37 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CC851CC.80509@freebsd.org> Date: Wed, 27 Oct 2010 19:22:36 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Garrett Cooper References: <201010270232.o9R2Wsu3084553@svn.freebsd.org> <4CC803A8.3040602@freebsd.org> <20101027082122.GD1848@garage.freebsd.pl> <4CC85552.2020100@freebsd.org> <20101027133307.GQ2392@deviant.kiev.zoral.com.ua> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, Pawel Jakub Dawidek , svn-src-all@freebsd.org, svn-src-head@freebsd.org, David Xu , Kostik Belousov Subject: Re: svn commit: r214409 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:22:41 -0000 [patch attachment was lost] on 27/10/2010 19:07 Garrett Cooper said the following: > How about this patch? I implemented this as a readonly tunable and I don't think that it's correct to call it a tunable or use CTLFLAG_RDTUN. As I understand it is a read-only sysctl. > sysconf tunable, because (AFAIK) the value that is being tested > shouldn't change during runtime after the system has been booted up, > and figuring that the value wasn't going to change it was better to > lose 4/8 bytes on the kernel stack instead of having to recompute the > value every time in a function call, with the associated lost heap / > stack memory in the process, as the assumption is that this libcall > was going to be called frequently by some programs. > Thanks! -- Andriy Gapon