Apologies to the OP, but I think we have drifted some way off helping you, but there is some, err, misunderstanding or mis-expression, in this thread and I really don't like the idea of deceptive material hanging around.

It seems that you have taken in too much of that wrong stuff and chosen to believe it, or at least, recycle a somewhat distorted version of the truth..

No. A 32 bit OS can handle a a 4G address space, but practically, within the PC architecture, when you take out the various holes for various bits and pieces of IO, you end up with being able to adress rather less memory than this.

This would be true, if it weren't for the memory holes. But the memory holes are a significant part of the picture when you you get towards 4G of ram (and want to use as much of it as you can).

Well, you can't turn it on and off dynamically, if that's what you mean (but its unclear why you would want to mean that, as no one has mentioned wanting to do this on a running system). But you can always choose not to use it (ie, use the non-PAE kernel) and put up with the 4G minus the memory holes.

according to the linux Partition howto http://lissot.net/partition/index.html you could have a limit of 2G per swap partition (or it could be 16T). That is arch dependant, and while we might agree that it would not be sane to get close to 16T, 2G (i386) is another matter. The document is a bit old by now ('05) and maybe things have changed in the latest kernels, but if the OP was running one of the more compact distros, intended for older hardware, this could be an issue.

PAE is not actually using the memory lost due to the holes. john has dealt with the problem of using, but, in fact, that is a poor expression: the problem is not so much using as not using. that is, losing due to holes, rather expending extra memory in page mapping.

• Redhat have done testing on this and find, in their target workloads (think server, rather than desktop) that there is roughly a 1% to 5% loss of performance when PAE is used. AFAIK, their testing did not encompass the case in which the non-PAE server swapped, but the PAE one didn't, which would reverse the situation somewhat.
• The allegation that PAE turns physical RAM into virtual memory is bizarre. the virtual memory system turns physical memory into virtual memory and PAE adds a level of paging to that. So, as you note yourself, if you have a virtual memory system like Linux, then you have virtual memory and PAE doesn't change that (actually, even that's not totally true; non-virtual memory systems are used in some embedded applications, although that's not really relevant to this thread).

Johnsfine wrote:
But, as far as I am aware, they don't. They are usually careful to say that you have a number of address lines or a certain address space and let people jump to the conclusion that they can use all of the address space for RAM, if they want to. Of course, even on archs on which the I/O is separately mapped, you wouldn't get the full amount for RAM, because you have to use some for a boot rom, and every hardware engineer would know that.

So, if you have a reference to an Intel manual saying "80386 can handle 4 GB of physical RAM" (and not 'up to' or 'physical address space for' or some other form of weasel words), I'd be interested.

Long ago, I worked on the hardware , bios and OS design of a hand held computer using a 486 cpu chip. That design mapped some of the ram at the same address as the boot rom. At system startup that section of ram was write only and the rom at the same address was, of course, read only. But after the bios code was done using the rom, the rom was turned off and the ram at the same address became ordinary read/write ram.

We didn't have GB's of ram, so there was no worry about whether there were holes in the 4GB address space. It just was a standard behavior of the available memory controller chip that the hole in the first MB could be turned on and off. Since our (non PC compatible) OS didn't use the rom nor any memory mapped I/O, we chose to switch shortly after boot to the mode where all of ram was contiguous without holes.

I don't think anyone now would make an x86 design that far from PC standards, but if you did so the boot rom isn't much of an issue.

Redhat often (maybe always, I'm not sure) ties PAE support together with the option to split the virtual address space 4GB/4GB instead of the usual 3GB/1GB. Are you sure the test you're quoting isn't a test of that feature?

Either the overhead of just PAE or the overhead of the 4GB/4GB split varies enormously based on the workload you select. But they are on a very different scale. The 4GB/4GB split usually has far more overhead than PAE alone.

I think you would need a maliciously chosen very strange workload for the overhead of PAE to get anywhere near 5% (usually it should be well under 1%) while the overhead of the 4GB/4GB split ought to be in the 1% to 5% range for some common server workloads (but may go way over 5% for other possible server workloads).

I doubt RedHat intentionally chose a workload to make the feature look bad, so I think the 1% to 5% must be the overhead of the 4GB/4GB split, not the overhead of PAE alone.

I have read that somewhere around 8GB to 16GB of ram, the usual 3GB/1GB split tends to cause the system to run out of kernel virtual address space and you need either the 2GB/2GB split, which reduces user mode virtual memory or the 4GB/4GB split which has extra overhead. I have used a 32 bit PAE server with 8GB of ram and the 3GB/1GB split without any problems with kernel virtual address space. I don't know what differences in workload mix might make the 1GB limit on kernel virtual address space more or less of an issue.

I have the hard copy titled "80386 Programmer's Reference Manual by Intel." It states 4 KB pages have to be used in order to handle 4 GB of RAM. Go read it. PAE hides the truth.