On Wed, 2006-04-12 at 12:51 -0400, Matt Roth wrote: > >> Eric Persson wrote: > >> > >> Hi, > >> > >> I have a Fedora core 3 machine: > >> > >> Fedora Core release 3 (Heidelberg) > >> Linux localhost.localdomain 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 > EST > >> 2004 i686 i686 i386 GNU/Linux > >> > >> It currently have 3gb of memory in it, and I have two spare slots which > >> I intend to fill with an additional 2gb of memory to get to a total of > >> 5gb in the machine. > >> > >> Is this possible or is there a 4gb limit in the kernel, which would > make > >> something like PAE needed. If so, is that already included in the stock > >> kernel used? > >> > >> Any other apparent caveats? > > > > Alexander Dalloz wrote: > > > > Does your motherboard support such an amount of RAM? You did not tell us > > which one you run. You should look into the manual. On non server i386 > > x86 boards the amount of RAM is often limited to max. 4 GB, where you > > even loose the amount which is required by I/O components. Thus you > > often only have max. 3.5GB RAM even if 4GB modules sticked in. > > Eric, > > In addition to Alexander's points, there are a few other things to > consider when installing more than 4 GB of RAM: > > 1) 32-bit processors (without 64-bit extensions, such as Intel EM64T) > are limited to 4 GB of physical memory. > > 2) 32-bit operating systems and applications use 32-bit pointers than > can only address up to 4 GB of physical memory. > > 3) 32-bit hardware (such as PCI ethernet cards) can be problematic. I > have a Level 5 Networks EtherFabric EF1-21022T that required a custom > driver for our system. I believe it was a DMA bounce buffering issue. > > If you don't have a 64-bit processor or a processor with 64-bit > extensions, you are limited to 4 GB of RAM. Since according to your > post you are running Fedora Core 3 i386, this is the most likely scenario. <snip> Actually, this needs a slight correction.... Yes, the processor can only natively address 4GB of RAM. This is also the case of the Uniprocessor kernel (aka. kernel-<version>.<arch>.rpm). There are, however, some alternatives that were implemented in Linux and, I believe, require mobo support (a la PAE or something like it). The SMP kernel (which it appears the OP is running, aka kernel-smp-<version>.<arch>.rpm), has a "mapping" function that allows it to address more than 4GB of RAM on a 32-bit architecture. The theory is support for up to 16GB of RAM in, what has been declared as a 1G/3G split. Of course, as you use the memory beyond 4GB, some context switching needs to occur, and the kernel itself can address only 1GB while an individual process can address only 3GB (hence the aforementioned split). But, of course, most of us are running more than one process, hence adding them up to a cap of 16GB..... Red Hat also introduced a "bigmem" or "hugemem" kernel package that changed the underlying memory architecture to a 4G/4G split and allowed us to extend addressable memory to 64GB on a 32-bit architecture - but again, only 4GB at a time and a need to context switch a bit. But, this made the database folks happy, who cannot seem to get enough RAM to cache with. I believe the general recommendation though these days, given that hybrid 64-bit CPUs from AMD and Intel are definitively mainstream is that we probably "should" migrate to one of these new processors when we look to exceed the native 32-bit capacity of 4GB, and hence, no more context switching.... But, of course, I'll defer those recommendations to the kernel developer types on the list.... :-) --Rob
