[Novalug] PAE extensions, any negative aspects?

Jon LaBadie novalugml at jgcomp.com
Thu Nov 13 12:06:08 EST 2008


On Thu, Nov 13, 2008 at 11:30:17AM -0500, Peter Larsen wrote:
> On Thu, 2008-11-13 at 11:15 -0500, Jon LaBadie wrote:
> > Are there any downsides to using the running
> > the PAE enabled kernel version?
> > 
> > I presume memory access has slightly more overhead.
> > A search on the internet turned up pages that were
> > mostly 3-6 years old but did not indicate any
> > significant problems.  Those that did say perform-
> > ance was affected said "1-10%" but cited no data.
> 
> I use PAE and don't see an issue. Here's the details about it:
> http://en.wikipedia.org/wiki/Physical_address_extension. This is a CPU
> feature.
> 
> Of course there's "overhead" when the computer creates virtual liniary
> address spaces. But all OS's have done that ever since the invention of
> Virtual memory. PAE allows 36 instead 32 bit address space and increases
> the size of the memory mapping. But it would be foolish to talk about a
> performance hit? Unless of course you feel that anything mapping
> physical memory is a performance issue, in which fall no OS will pass
> muster.

However, if there were no issues, then I'd expect PAE to be
the default kernel configuration.


> It's worth remembering that this solves the problem of the largest
> SINGLE allocated program. It's been possible for a long time to use more
> than 4GB on 32bit machines. Just not for the same program.

I think you mean "does not" solve the problem.  I ran into that
with a client a few years ago.  For cost reasons wanted to
run his commercial application on RH 7.3 rather than Solaris
Sparc (the license fees were much lower).  But this meant
going 64-bit to 32-bit.  He did not understand why his
dual Xeon boxes with 10GB of RAM (yes a strange amount)
sometimes ran out of memory.  Against recommendation he
wanted to solve it by increasing swap to 16GB on each box.

Of course there was no improvement because the problem was
the limit per-process and that is not changed by increasing
the amount of RAM and swap.

-- 
Jon H. LaBadie                  jon at jgcomp.com
 JG Computing
 12027 Creekbend Drive		(703) 787-0884
 Reston, VA  20194		(703) 787-0922 (fax)



More information about the Novalug mailing list