On Mon, 2006-06-12 at 14:35 +0200, Per Jessen wrote:
But we are talking about an application accessing memory, which on Linux is done exclusively through the virtual memory manager. That the VMM will use the PAE for addressing up to 64Gb of physical memory does not concern the application.
But how does the 32-bit application use its pointers to access and differentiate more than 4GiB? And that's _before_ we even look at how the application's object code is actually built into a memory model the kernel can support. I think people keep confusing the difference between "total userspace" among _all_ applications and "total userspace" used by *1* application. Segmentation, translation paging, etc... is addressed by the kernel for _all_ applications. But then you have "hard" 32-bit limitations in the application itself for x86. That's when both the application code and object code memory model _really_ come into play!
OK - do you know how this is done on Linux? I'm really curious as I've always considered this kernel-only stuff. I have no problem with the concept of mapping physical memory (normally not used by the kernel) into my own address-space, I just did not think Linux provided that option.
Oracle uses it. One of the reasons I implemented Opteron/x86-64 as soon as it became available in 2004 was because of the 2.5GiB "base" 32-bit of Oracle 9/10, and performance hit for using more.
My understanding of Linux' use of PAE is that enabling CONFIG_HIGHMEM64 essentially makes the kernel switch to a three-level instead of a two-level address lookup.
That's another story. People keep merging different kernel, API and ABI concepts. The kernel gives you more than 1-3GiB for _all_ applications through various modes -- including virtualizing memory. The application can use more than the hard 32-bit/4GiB pointer limitations by various techniques, as well as has to be built against the memory model the kernel supports (for more than 1-3GiB). It's easy to use page translation at the x86 kernel level to provide _more_ than 1-3GiB or even 4GiB of physical RAM to _different_ applications. The application-level issues arise when the x86 kernel attempts to allow an application to use more than 1-3GiB (using compile-time/directives) or even 4GiB (which requires some application code changes) for a _single_ application. AMD solved it very nicely with "Long Mode" for up to 48-bit physical addressing (although it's currently a 40-bit platform limitation in how EV6 works, which also affects A64/Opteron too) and then put in compatibility with PAE as well. You can't just do a "malloc" on x86 Linux and get more than 4GiB. -- Bryan P.S. the "3GiB" model for programs to use is not limited to x86 Linux. There is a "3GiB" model for x86 NT as well, including applications built for it (that won't run unless you pass an option to enable it in the boot.ini). -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ------------------------------------------------------- Illegal Immigration = "Representation Without Taxation" -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com