Date: Thu, 2 Aug 2001 07:35:05 -0300 (BRST) From: Rik van Riel <riel@conectiva.com.br> To: Terry Lambert <tlambert2@mindspring.com> Cc: craig <craiglei@pasia.com.cn>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: How to visit physical memory above 4G? Message-ID: <Pine.LNX.4.33L.0108020728100.5582-100000@duckman.distro.conectiva> In-Reply-To: <3B692AE3.4B119794@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2 Aug 2001, Terry Lambert wrote: > Rik van Riel wrote: > [ ... > 4G on 32 bit macines ... ] > > > 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. > > No. It still bites you if you want to do IPC, etc., since you > can not guarantee the structures used for this are all within > the non-segmented region of memory. Wrong. Your process can have pages from all over the 64 GB mapped into its page tables. Each process has 3 GB of virtual memory mapped to any of the pages of the 64 GB of physical space. > > Only the FreeBSD memory management subsystem doesn't > > support it (yet?). > > It's not a question of "supporting it", it's a question of > whether or not it's a useful idea at all. > I have yet to see one person using it for anything. So far, > it is nothing more than marketing fodder: I haven't seen one > motherboard capable of more than 4G worth of SIMMs. I've seen a bunch of the machines. They're rather popular with the database folks. > > 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 it's not unreasonable to think of putting 8G or 16G in > a box, and being able to map it all. You can never map it all, since your virtual address space is limited to 4GB... > > 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. > > Not really. There's always 4M pages. Hmm, indeed. I guess I should sleep more since I've been planning this solution for Linux, too ;) Basically the database folks are really keen on keeping their 3GB user addressable memory, so the kernel will remain limited to 1GB of KVA. On the really large machines, this can lead to the situation where even the page tables hardly fit into KVA. 4MB pages seem like the only solution ... (well, there's also the mess of shared page tables, but nobody is keen on the locking issues those imply) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33L.0108020728100.5582-100000>