From owner-freebsd-hackers Thu Aug 2 6:38:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 670F237B401 for ; Thu, 2 Aug 2001 06:38:39 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac2.wam.umd.edu (IDENT:root@rac2.wam.umd.edu [128.8.10.142]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id JAA20566; Thu, 2 Aug 2001 09:38:00 -0400 (EDT) Received: from rac2.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac2.wam.umd.edu (8.9.3/8.9.3) with SMTP id JAA21576; Thu, 2 Aug 2001 09:38:00 -0400 (EDT) Received: from localhost (culverk@localhost) by rac2.wam.umd.edu (8.9.3/8.9.3) with ESMTP id JAA21572; Thu, 2 Aug 2001 09:38:00 -0400 (EDT) X-Authentication-Warning: rac2.wam.umd.edu: culverk owned process doing -bs Date: Thu, 2 Aug 2001 09:38:00 -0400 (EDT) From: Kenneth Wayne Culver To: Rik van Riel Cc: Terry Lambert , craig , freebsd-hackers@FreeBSD.ORG Subject: Re: How to visit physical memory above 4G? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Also, the PIII CAN'T natively support more than 4GB of ram. If a particular PIII motherboard supports this, then it's using some kind of wierd chipset that allows this to happen. 4GB is the limit with a 32 bit chip I believe; and the PIII is a 32-bit chip. Ken On Thu, 2 Aug 2001, Rik van Riel wrote: > On Wed, 1 Aug 2001, Terry Lambert wrote: > > > craig wrote: > > > > > > > > > I know PIII can support 64G physical memory. In FreeBSD how can I visit such > > > range memory(4G-64G) ? > > > > The short answer is "you can't". > > > > The longer answer is that you end up having to window it using > > segmentation; > > Only if you want to use it all within one process. > > You can have multiple 2 GB (that's the maximum > process size in FreeBSD, right?) programs at the > same time, happily using all physical memory. > > Only the FreeBSD memory management subsystem doesn't > support it (yet?). > > > This basically means that the memory is useless as a DMA target > > or source for disk controllers or gigabit ethernet cards, and is > > pretty useless for swap, ... > > > So for limited uses in data intensive applications, it might be > > usable, > > And for those data intensive applications, it is very > useful indeed... > > > But to directly answer your question: by rewriting much of the > > low core virtual memory and page mapping handling code to know > > about segmentation. > > Not just that. There is a more insidious problem with > the FreeBSD VM code and support of huge machines. > > The part of handling the PAE extended page table format > and mapping high memory pages in and out of KVA (kernel > virtual address) memory to copy stuff is easy. > > Problem is that you'll have to fit all of FreeBSD's VM > data structures in the 2GB of KVA. This just isn't going > to fit with the size the data structures have today ... > > So in order to support huge memory machines "right", > you'd have to put a number of FreeBSD's VM data structures > on a rather strict diet. > > regards, > > Rik > -- > Executive summary of a recent Microsoft press release: > "we are concerned about the GNU General Public License (GPL)" > > > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message