Mailinglist Archive: opensuse (3605 mails)

["Bryan J. Smith" <b.j.smith@xxxxxxxx>]

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@xxxxxxxx  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@xxxxxxxx
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@xxxxxxxx