From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 17:59:05 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1F5B106572E; Tue, 9 Nov 2010 17:59:05 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh4.mail.rice.edu (mh4.mail.rice.edu [128.42.199.11]) by mx1.freebsd.org (Postfix) with ESMTP id BC6A58FC1D; Tue, 9 Nov 2010 17:59:05 +0000 (UTC) Received: from mh4.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh4.mail.rice.edu (Postfix) with ESMTP id 197C728F7F0; Tue, 9 Nov 2010 11:59:05 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh4.mail.rice.edu, auth channel Received: from mh4.mail.rice.edu ([127.0.0.1]) by mh4.mail.rice.edu (mh4.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id j7-SWtG-nMk8; Tue, 9 Nov 2010 11:59:05 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh4.mail.rice.edu (Postfix) with ESMTPSA id 832E628F7EA; Tue, 9 Nov 2010 11:59:04 -0600 (CST) Message-ID: <4CD98BE7.7030208@rice.edu> Date: Tue, 09 Nov 2010 11:59:03 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Julian Elischer References: <4CD97A9A.8000007@freebsd.org> <20101109170453.942D95B89@mail.bitblocks.com> <4CD982E9.70500@freebsd.org> In-Reply-To: <4CD982E9.70500@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 09 Nov 2010 18:08:38 +0000 Cc: alc@freebsd.org, FreeBSD Current Subject: Re: limits to memory on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 17:59:06 -0000 Julian Elischer wrote: > On 11/9/10 9:04 AM, Bakul Shah wrote: >> On Tue, 09 Nov 2010 08:45:14 PST Julian >> Elischer wrote: >>> During the discussion at MeetBSD the question came up as to what the >>> real >>> limiting factors were with regard to how much RAM a system could have. >>> it was put to us that the limit was currently around 512 GB, though >>> no-one >>> at teh discussion knew what the mechanism of the limitation was or >>> what might ligh beyond it. >>> >>> Could anyone who knows, pipe upt and let use know what the factors are, >>> and if the current limit is overcome, what the next one after that >>> will be? >> You mean beyond architectural limits? > > no, though of course they are relevant. > I was thinking more of details like limits to the KVM space or > any limitations there may be on the size of the direct-map region, > or maybe some limit on some data structure size in the kernel. > Since I don 't know the details, this is exactly the question.. > what IS the limit? The changes to support more than 512GB RAM should be straightforward. Off the top of my head, it will require some constant definitions in vmparam.h to change, and the allocation of some additional PDP-level page table pages in create_pagetables(). In contrast, the changes to break the original 2GB KVM barrier involved touching a number of different places in the kernel. Alan