Roger Heflin wrote:
I know a bios engineer once told me that some chipsets/bios can only
remap entire dimms (not parts of a dimm) and doing an entire dimm would
result in only 2GB below 4GB and that bothers some vendors since it
would cause issues with memory availability with 32bit only OSes.
That's clearly not the case in general, and I've never seen it. Only old CPUs
would have a problem with it (as a hardware issue), since all x86 CPUs recently
support PAE for 64GB physical memory. I have never seen any 32 bit MSFT product
use PAE, but the PAE Linux kernels will use more than 4GB, which is fine as long
as no user program tries to use more than 4GB.
Notes:
- using PAE results in a performance reduction. I have never found it to be a
net loss, more memory makes the system faster to a greater extent than PAE makes
it slower (my experience).
- 32 bit versions of many programs run faster than the 64 bit version, because
they are smaller and nicer to cache. This is another small effect, not a big deal.
- 2.6.27 offers both MTRR "cleaning" and use of PATs. Read the linux kernel
mailing list and Intel docs for PATs, LKML for MTRR cleaning. Short answer is
that you are likely to use memory better with 2.6.27 and later, that's certainly
the case in my experience.
Check to see if any bios settings change things, on the higher end
boards there use to be a memory hole setting that could be set to
hardware or software, though if I remember correctly setting it such
that you found all of the memory also resulting in the machine being a
couple of percent slower.
You show your age by remembering that, and I show mine for remembering the
details. It seems that some hole settings resulted in using memory which
couldn't be cached (not enough address bits in cache memory). That made the
memory so slow that programs were written to use it for swap or ramdisk. I had
such programs for both MS-DOS and Xenix.
--
Bill Davidsen <davidsen@xxxxxxx>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
