According to Red Hat here are the OS limitations,
http://www.redhat.com/rhel/compare/

I am wanting to know ... when using a kernel that supports memory over 4GB, are applications still limited to using only 4 GB?

IE. If 14 GB is available, can one application use 6GB of the 14GB at one time?

Thanks,
/Jason

http://kerneltrap.org/node/2450 : see solution 3.

Basically, each process has a 4GB virtual memory size (which may or may not be wholly allocated). About 1Gb of this space is reserved for the kernel, so you can access 4Gb of virtual memory in any one process.

I believe that you can overcome this by using a tmpfs filesystem (like /dev/shm/) to store data in an in-memory filesystem structure larger than 4Gb. But I've never tried this myself.

Unfortunately, the x86 32-bit instruction set simply doesn't have any instructions to use addresses bigger than 32 bits.

Hope that helps,

—Robert J Lee.

Most, maybe all, of those look like license restrictions, not technology restrictions.

Someone else mostly manages the Red Hat and Centos systems where I work, and so far the answer to any licensing issue has been switch that system from Red Hat to Centos. I didn't know Red Hat had so many license choices and I don't know which are covered by Centos.

But anyway, you seem to be trying to ask a technical question, not a license question.

I assume you mean x86, not x86_64. In x86_64 the per process virtual memory limit is somewhere well above where anyone should care yet.

In normal x86, each process is limited to 3GB, because the kernel uses 1GB of each 4GB address space. There is a 32 bit kernel version in which kernel memory is in a different address space, so each process can use 4GB. But that is an ugly kludge.

If 14 GB is available, you probably have a CPU that can run an x86_64 kernel, and if you care whether one application can use 6GB you should be running an x86_64 kernel.

I assume you mean to create some kind of software demand paging (probably on a chunk size much larger than a page) by demand mapping a tmpfs as a form of named shared memory.

I don't know enough about named shared memory to know how demand mapping that would compare to demand file mapping into a tmpfs. I'm sure one or both of those could be made to work for efficient use of more than 4GB of physical ram by a 32-bit program. But why bother?

If you manage to have one of the few old motherboard/CPU combinations that has 16GB of ram without x86_64 support, I'm sorry you wasted your money back when that was expensive, but dump it. A new (faster) CPU and motherboard and 16GB of faster ram is very low cost compared to the aggravation of doing 6GB per application computing with a 32bit CPU.

You link to a page which covers memory capacity by RHEL version, although you need to read the notes carefully; is your question because you are not using RHEL or because you have not been able to get the info that you want??? (With a support contract, RH support should be able to give you an answer to this by return of e-mail; if they aren't answering a question like this, this would be a big negative for them.)

The PAE kernel (which may or may not be available in a version of RH; the page that you quote isn't clear about which kernel.org kernel is which of their kernels) supports more than 4G of memory on a 32 bit system; the processor has to support the relevant instructions of course; anything modern will, but more exact definitions are on the wikki page.

It does still, afaik, have the 4G max per process limitation, even though the system as a whole can use more memory than that. If you are close to that limit, you really should be considering the 64 bit kernel.

The 64 bit kernel supports larger amounts of memory; to me it currently seems to support infinite amounts of memory in that the limit is set at a value of 'more than I am prepared to afford', which might as well be infinite.