From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 12 08:08:51 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42002106566C; Thu, 12 Aug 2010 08:08:51 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 92CAC8FC1C; Thu, 12 Aug 2010 08:08:49 +0000 (UTC) Received: by bwz9 with SMTP id 9so896486bwz.13 for ; Thu, 12 Aug 2010 01:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WTMGZXv7oIBkogFhwoZPAImsc4uPVJR2KuTgcREASLY=; b=EmBFYSlewjg6hSITuP9WS2qxvzFtHVpM638b4pwpDOAtUBtvKK14if9EjLB8F53UAQ g7QiJiBJb34FYVBelyG4MVzOQsumNz7AwaPus3cSdcX0JoBT0uikcByS4z42U/Xe+XuJ EkOCQX4MD58jsUk52X/liAsAMZSZC4BjHqiu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Xh/T+1kbTs8t/c47+YDhBZmOmihEXkolUTnnyK0t0MrmwXHN/18+9PNRQM3N1aIsOX 6MTzAP+d2VZebkbe9VhSHPYutsaNV0pdjGRisNxBo7xxiZ50i1NSSjaZbYjhxUGk3VAd bFhbYr/zrHvDOcOYXH6Lqlu9zLaVfuWcoq6oE= MIME-Version: 1.0 Received: by 10.204.146.153 with SMTP id h25mr408792bkv.86.1281600528292; Thu, 12 Aug 2010 01:08:48 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.204.82.6 with HTTP; Thu, 12 Aug 2010 01:08:48 -0700 (PDT) In-Reply-To: <8662zkurx9.fsf@ds4.des.no> References: <86fwyq8rsc.fsf@ds4.des.no> <86d3tujh72.fsf@ds4.des.no> <864of680wv.fsf@ds4.des.no> <8662zkurx9.fsf@ds4.des.no> Date: Thu, 12 Aug 2010 01:08:48 -0700 X-Google-Sender-Auth: gRuHbC6J8Xg88knfbksyFdLZHOg Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 08:08:51 -0000 2010/8/9 Dag-Erling Sm=F8rgrav : > Garrett Cooper writes: >> Why would someone express a tunable in a memory address (not being >> sarcastic... I just don't see why it makes sense right now, but if >> there's a valid reason I'm more than happy to be educated :)..)? > > A few examples: > > hw.acpi.host_mem_start > hw.pci.host_mem_start > hw.physmemstart > > The following are not addresses, but can be > 32 bits on 64-bit machines > and even on some 32-bit machines using PAE / PTE: > > hw.physmem > vm.kmem_size > vm.kmem_size_max > vm.kmem_size_min Ok -- good to know. > It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE. I would actually argue against doing that because it would only create divergence between sysctl and tunable KPIs... but that's just me. The patch I provided before would converge sysctl and tunables a bit more (and I'd more than happily submit patches for the other missing cases on the sysctl side to get parity with the tunables). If it makes sense to add the sysctls _and_ the tunables for POINTER and SIZE though, I'll provide a patch for both cases in one shot. (BTW, when you say TUNABLE_SIZE, I assume it would be a size_t quantity?) Something might need to be done to the values returned by the tunables though, because they don't respect boundaries, and can overflow right now (which exacerbates the issue with values crammed into smaller datatypes)... Thanks! -Garrett