Date: Thu, 02 Aug 2001 03:26:43 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Rik van Riel <riel@conectiva.com.br> Cc: craig <craiglei@pasia.com.cn>, freebsd-hackers@FreeBSD.ORG Subject: Re: How to visit physical memory above 4G? Message-ID: <3B692AE3.4B119794@mindspring.com> References: <Pine.LNX.4.33L.0108020543070.5582-100000@duckman.distro.conectiva>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. The default maximum size for FreeBSD is 3G. You can tune this up or down, with the limit being that the larger the user space, the smaller the KVA space, and vice versa. > 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. > > 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... 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. > > 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. Not really. > 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. Yes. > 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 ... I currently run with 3G+ of KVA; it would be simple to invert this, but this leaves me a 1G user space window, with 3G available for kernel structures, etc.. It takes about 1G for all of the kernel support stuff for 4G, with an allowance for 1/8th million open network connections. So it's not unreasonable to think of putting 8G or 16G in a box, and being able to map it all. > 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. -- Terry 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?3B692AE3.4B119794>