From owner-svn-src-all@FreeBSD.ORG Thu Jan 23 05:50:23 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C30D39A0; Thu, 23 Jan 2014 05:50:23 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A9D6D1151; Thu, 23 Jan 2014 05:50:23 +0000 (UTC) Received: from Alfreds-MacBook-Pro.local (unknown [50.204.88.5]) by elvis.mu.org (Postfix) with ESMTPSA id CBB371A3C26; Wed, 22 Jan 2014 21:50:21 -0800 (PST) Message-ID: <52E0AD9A.2000704@freebsd.org> Date: Wed, 22 Jan 2014 21:50:18 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rui Paulo , Adrian Chadd Subject: Re: svn commit: r260898 - head/sys/kern References: <201401200159.s0K1xa5X012123@svn.freebsd.org> <1536225.gsjt6oXMt2@pippin.baldwin.cx> <0F26E4E1-5D75-413E-B92B-AA7092B87D89@FreeBSD.org> In-Reply-To: <0F26E4E1-5D75-413E-B92B-AA7092B87D89@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Neel Natu , John Baldwin X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 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: Thu, 23 Jan 2014 05:50:23 -0000 On 1/22/14, 8:34 PM, Rui Paulo wrote: > On 22 Jan 2014, at 20:05, Adrian Chadd wrote: > >> .. Make it be an offset into the table rather than a pointer, then we can do dirty rcu style hacks to just replace and grow the table as we need more memory. >> >> Don't we have a standard way to pull memory from the top of the physmem area early on for allocations like this? > Perhaps a bit overkill for this problem? Probably.. I keep thinking we should just increase the size by 2x but allow platforms to override. for "SMALL". -Alfred