From owner-freebsd-current@FreeBSD.ORG Tue Nov 9 17:20:41 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 6545A106566C; Tue, 9 Nov 2010 17:20:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id E89B18FC21; Tue, 9 Nov 2010 17:20:40 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oA9HKcjq014132; Tue, 9 Nov 2010 09:20:39 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id C260B2D6011; Tue, 9 Nov 2010 09:20:37 -0800 (PST) Message-ID: <4CD982E9.70500@freebsd.org> Date: Tue, 09 Nov 2010 09:20:41 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Bakul Shah References: <4CD97A9A.8000007@freebsd.org> <20101109170453.942D95B89@mail.bitblocks.com> In-Reply-To: <20101109170453.942D95B89@mail.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 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:20:41 -0000 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? > > From Wikipedia: > > Larger physical address space: The original > implementation of the AMD64 architecture implemented > 40-bit physical addresses and so could address up to 1 TB > (2^40 bytes) of RAM. Current implementations of the AMD64 > architecture (starting from AMD 10h microarchitecture) > extend this to 48-bit physical addresses and therefore > can address up to 256 TB of RAM. The architecture permits > extending this to 52 bits in the future (limited by the > page table entry format); this would allow addressing of > up to 4 PB of RAM. >